Vizualizace C++ kódu – CodeViz

25.7.2010 09:56 | Přečteno: 2046× | Programování | | poslední úprava: 25.7.2010 16:25

Čtení a snaha porozumět cizímu kódu může zabrat mnoho času, protože se kód může dotýkat mnoha částí programu. Pokud člověk chce kódu porozumět v globálním měřítku, často se to neobejde bez různých obrázků. Proč si to nezautomatizovat?

Úvod aneb o co jde

Snad všichni znají nástroj call grind, který umí generovat call graph. Ovšem i ten má své hranice. Bohužel ten při použití s programem, u kterého bych si rád call graph vygeneroval padá. Navíc pokud jeho funkci chápu správně generuje call graph jenom pro konkrétní běh programu. Jinak řečeno, hledám program, který tohle zvládne vytáhnout ze zdrojového kódu.

Asi první věc, na kterou narazíte při hledání call graph je článek na Wikipedii. Ze jmenovaných nástrojů se zdá, že CodeViz je přesně to, co hledám.

Quest za funkčním CodeViz

Jak už to tak bývá ne vše je tak snadné jak se zdá. CodeViz může používat pro zjištění jmen funkcí dvě cesty. Ta snazší je pomocí objdump. Druhou cestou je cesta s využitím opatchovaného gcc 3.4.6.

Netrvá dlouho a už na mě z konsole kouká hláška make[1]: *** [all] Error 1 a nějaké ty další chyby. Kompilátor se tváří, jako kdyby některé #define nebyly definovány, i když jsou. Není to první podobný problém s gcc 4.5 co mám. Strávil jsem skoro celý den hledáním čistého řešení. To jsem nenašel a skončil jsem u prasáckého zakomentování všech postižených #ifdefů. Tak, konečně se mi to podařilo zkompilovat a nainstalovat a hned CodeViz zkouším. O tom ale později.

Vzhledem k pracnosti zprovoznění opatchovaného gcc jsem se rozhodl udělat PKGBUILD pro Arch Linux. Dalších půl dne v prdeli. Rozhodl jsem se totiž kompilovat gcc ručně, bez použití skriptu v CodeViz. V samotném skriptu narazíte na vtipnou věc. Totiž když kompilujete gcc 3.4.6, tak to skončí chybou. Configure skript totiž u špatně vytvoří config.h pro libiberty. Zvláštní je, že pokud se dělá bootstrap tak se poprvé vygeneruje správně, pro finální kompilaci ale už ne. Řešením je tedy make || true, aby makepkg neskončilo na chybě kompilace, zkopírováním části install skriptu z CodeViz a znovuspuštením make.

Ale ouha, zase to nefunguje. Nové verze makepkg mají totiž ve chvíli, kdy nějaký příkaz vrátí 1 okamžitě skončí s chybou. Proto jsem také při prvním volání make použil make || true abych se tomu vyhnul. Teď ale narážím na problém, kdy se testuje výstup grepu, jestli není náhodou nulový. Problém je, že grep v tom případě skončí s návratovým kódem 1 a tudíž shodí makepkg. Tady true už nepomůže. Naštěstí stačí postižený test vyhodit. Co to udělá na cizím stroji nevím, ale předpokládám, že ten test dopadne na všech Arch Linuxech stejně.

Jak to funguje

Funguje to, ale má to své masařky. Nejdřív začnu tím, jak to funguje. Pro začátek musíme vygenerovat soubor s grafem. Na to je v CodeViz skript genfull. Podle potřeby nastavíme jak má získat potřebné symboly a jazyk (C/C++).

Začnu tím jednodušším a tím je získání symbolů pomocí objdump (parametr -g cobjdump pro C resp. cppobjdump pro C++). V tomhle případě genfull rekurzivně prohledá aktuální adresář a hledá binárky, pro které vytvoří soubor full.graph. Samozřejmě binárky musí obsahovat debug symboly, jinak je to k ničemu. Nevýhodou tohohle řešení je, že neuvidíte inlinované fce (ledaže byste vypnuli inlinování).

Samozřejmě o předchozí možnosti jsem se dozvěděl až po tom, co jsem prošel martyriem s kompilací gcc. Takže teď ta horší cesta s gcc. Nejdřív musíme program, pro který chceme callgraph vygenerovat zkompilovat s pomocí opatchovaného gcc. Ten vytvoří ke každému zdrojovému souboru soubor s příponou .cdepn obsahující závislosti. Pokud se program linkuje s nějakou systémovou knihovnou, tak to samozřejmě nepůjde (myšleno na moderní distribuci kompilované gcc 4.x). Naštěstí k linkování dochází až na konci, takže soubory .cdepn jsem získal. Použití genfull je v zásadě stejné, akorát tentokrát vybíráme z možností -g cdepn a cppden.

A nakonec k vygenerování callgraphu. full.graph by prý mělo jít nacpat rovnou do dot (součást GraphViz), ale to nedoporučuji. Callgraph je i u malého projektu dost rozsáhlý na to, abyste se ho vůbec dočkali. Proto CodeViz obsahuje skript gengraph. Ten umožní nastavit nějaká omezení, například maximální hloubku a u které funkce se má začínat. Pokud nespecifikujete jinak, tak se jako výstup použije PostScript.

A nakonec k mouchám. I s použitím gengraph je generování callgraphu dost pomalé (hloubka >3 už se ani nevyplatí), navíc výsledný graf není zrovna přehledný (vždy jsem dostal příšernou nudli). Aby toho nebylo málo, pokud byl graf velký, měl jsem velké problémy s jeho otevřením. Okular i gv si na něm vylámali zuby, gv navíc řvalo nějakou chybu, takže je dost možné, že ps bylo vadné. Používat jiný výstup (konkrétně png) se mi neosvědčilo, kvůli použití Cairo backendu. Ten totiž nezvládne velké bitmapy a výsledek zmenší tak, že je z něj nečitelná mazanice. V mém případě výsledek zmenšil ca 10x.

Závěr

Ačkoliv CodeViz dělá to co má, vůbec mi nevyhovuje a nakonec používám jiný soft, ale o tom až jindy.

PS: Omluvte případné chyby ale nechce se mi to po sobě číst.

       

Komentáře

[stativ]

Příloha:

• vigra__CachedFileImageDirector__allocateBlock.ps (81350 bytů)

Ukázkový postscript.

[____]

To je teda pěkná šílenost.

[stativ]

Vždyť říkám, nudle

[Semo]

Ked som to zvacsil, aby vyska bolo priblizne ako obrazovka (a sirka ako 40 obrazoviek), tak "Okular closed unexpectedly".

[Jirka P]

A poslal jsi bug do KDE bugzilly?

[Semo]

Nie, tam som ich uz naposielal a na vsetky do jedneho sa vysrali. Ale mozno im dam este sancu, ked sa dobre vyspim.

[Luboš Doležel (Doli)]

Hmm, mně to sice nespadne, ale taky se mi tam vůbec nic neukáže - je tam jen logo Okularu.

[Grunt]

Sám jsem na samotný článek na Wikipedii narazil docela nedávno (jen pár dní zpět) a byl jsem popravdě docela překvapen. Já zas pro změnu hledám něco co by umělo vypisovat v reálném čase do konzole funkce, tak jak jsou volány za sebou, ale zdá se, že u call graphů jsem narazil. Jinak co zkusit klasickou GNU utilitu GNU cflow (neumí generovat, žádnou grafiku, ale jen textový výstup a ASCII Art což by v případě větších projektů zase mohlo být malé plus) a spojit ho Graphvizem (ten zas pro změnu bere výstup z cflow a umí z něj vygenerovat klasický graf).

[stativ]

cflow umí jenom C, na C++ si vyláme zuby.

Jinak to co hledáš by mohl umět callgrind, protože sestavuje callgraph za běhu (nezkoušeno). Pokud by ti stačilo tracovat jenom volání externích knihoven, tak by mohlo pomoci latrace (taktéž nezkoušeno).

[Grunt]

Jo, callgrinda jsem též zkoušel (společně s KCacheGrind – též doclea dobré), ale ten za běhu generuje callgrind.out.<pid> a navíc je docela složitý.

[Grunt]

Kecám. Ne s cflow, ale s gprof.

[stativ]

gprof generuje call graph za běhu, což se mi moc nehodí.

[Grunt]

Se zas hodí mně, ale nehodí se mi, že to zase za běhu nevypisuje. To si člověk dneska nevybere.

[elviin]

Na vypis funkci muzete pouzivat napr. v debug modu __LINE__, __PRETTY_FUNCTION__, __FILE__.

[Grunt]

To se mi ňák nezdá. To jsou standardní makra, ne? Nebo se od do co jsem se s nima učil něco změnilo?