Portál AbcLinuxu, 20. května 2025 20:39
V tomto zápisku si probereme možnosti debugování pomocí nástroje GDB. Jde o výcuc z podrobnějšího tutoriálu, který je publikován na mém webu.
GDB je velice známý nástroj s dlouhou historií, přesto pouze málo programátorů dokáže využít všechny nabízené možnosti. Programátoři se dokonce často raději spoléhají na vlastní ladící prostředky (debugovací výpisy). Častým důvodem je původní CLI rozhraní GDB, nicméně to není v současné době jediná možnost. GDB má v standardu i TUI a není problém použít některý z propracovaných front-endů.
GDB je možné spustit s parametry určujícími jaký program chceme debugovat.
Nejdůležitejší parametry, které můžeme specifikovat při spuštění gdb jsou:
gdb program gdb program PID gdb program core gdb --args program parametry programu gdb -exec binarka -symbol soubor_se_symboly -pid PID -core core_soubor gdb < soubor_s_prikazy
GDB má velice propracovanou nápovědu dostupnou pomocí příkazu help. Ten ve verzi bez parametrů vypíše jednotlivé kapitoly nápovědy. Podrobnou nápovědu si pak můžeme vypsat pomocí help kapitola, nebo help prikaz. Pokud potřebujeme v nápovědě vyhledávat, můžeme použít příkaz apropos vyraz.
Když už máme gdb spustěné, můžeme začít debugovat. Pokud máme program, který padá, budou nám stačit příkazy run a backtrace. První z nich program spustí, pokud program vyvolá některý ze signálů, automaticky ho gdb zastaví. Pak se pomocí příkazu backtrace můžeme podívat na aktuální obsah stacku, přičemž přidáním parametru full dojde i k vypsání lokálních proměnných. To samé můžeme provést i bez spouštění programu v GDB, stačí když máme k dispozici core soubor vygenerovaný pádem programu. Pokud se nám core soubor negeneruje automaticky při pádu programu, můžeme si toto vynutit pomocí příkazu ulimit -c unlimited (tento příkaz patří do konzole, ne do GDB).
Breakpointy jsou mocným nástrojem. Pokud už jsme odhalili místo kde nám program padá, což jsme si ukázali v předešlé kapitolce, potřebujeme často přesněji zjistit kde problém vzniká.
Alternativou k příkazu run je příkaz start. Ten funguje naprosto stejně, nicméně zároveň nastaví breakpoint na funkci main. Po zastavení na breakpointu, můžeme běh programu obnovit pomocí příkazu continue.
K nastavování breakpointů slouží příkaz break lokace. Lokací může být název funkce, číslo řádku, číslo řádku v konkrétním souboru, nebo adresa. Pokud chceme nastavovat breakpointy hromadněji můžeme použít příkaz rbreak regexp, který nastaví breakpoint na všechny funkce odpovídající uvedenému regulárnímu výrazu.
Breakpointy můžou být podmíněné, break lokace if vyraz, provede nastavení breakpointu na uvedenou lokaci. Když program dorazí na uvedenou lokaci, dojde k vyhodnocení výrazu. Pokud se tento vyhodnotí na nenulovou hodnotu, dojde k zastavení programu.
Na breakpoint můžeme ještě navázat sadu příkazů, které se mají provést při vykonání breakpointu. Pomocí následujícího bloku kódu nastavíme breakpoint na funkci, který přenastaví proměnnou x na hodnotu 3.
break funkce commands set var x=3 continue end
Zajímavou alternativou k breakpointů jsou watchpointy. Ty nehlídají pozici v programu, ale hodnotu nějakého výrazu, pokud se hodnota změní, je program zastaven. Kromě hodnoty, pak ještě můžeme hlídat čtení a zápis do proměnné. Watchpoint nastavíme pomocí příkazu watch vyraz.
Krokovat program můžeme pomocí příkazů step a next. Oba krokují po jednotlivých příkazech, nicméně step se zanořuje i do volaných funkcí, next zůstává v aktuálním bloku.
Pro rychlejší posuny v programu, můžeme oběma předešlým příkazům přidat parametr určující počet kroků, nebo použít pokročilejší příkazy finish, until a advance. finish provede program do konce aktuálního bloku, until provádí program až po uvedené místo (které musí být v aktuálním bloku), advance pak umožňuje pokročit i na místo mimo aktuální blok.
Čtení proměnných provádí příkaz print. Ten je inteligentní a vypisuje proměnné podle jejich typu. Například u pointeru ale není moc možností, jak odhadnout způsob výpisu, proto umožňuje gdb specifikovat styl výpisu. Pomocí print promenna@pocet, vypíše proměnnou jako pole o uvedeném počtu prvků, případně můžeme přímo určit styl výpisu a specifikovat pouze adresu, kde se námi požadované data nacházejí.
Zápis proměnných se provádí pomocí příkazu set var promenna=hodnota.
TUI by mělo být k dispozici přímo po instalaci gdb. Spustit jej můžeme pomocí příkazu gdbtui, nebo gdb -tui. TUI se skládá ze dvou textových oken. Ve vrchním je zobrazen zdrojový kód aktuálně debugovaného programu, ve spodním je klasická gdb konzole. TUI podporuje vlastní klávesové zkratky, které urychlují práci. Jejich seznam najdete v manuálu GDB.
Insight je velice kvalitní grafický front-end pro gdb. Jeho hlavní výhodou je, že je to opravdový čistokrevný front-end. Pokud chcete můžete si otevřít klasickou GDB konzoli, které je s GUI provázaná. Na rozdíl od ostatních GUI tak neschovává některé důležité funkce GDB.
Velkým problémem GDB je chybějící podpora pro standardní typy C++. Pokud jste si někdy zkusili vypsat některý typ z STL, určitě víte, že dostat se k datům, které daná proměnná obsahuje, je prakticky nemožné. Naštěstí GDB umožňuje definovat vlastní příkazy a tak se našli programátoři, kteří pro nás připravili speciální příkazy pro výpis jednotlivých datových struktur C++. Soubor s definicemi si můžete stáhnout například tady: http://www.simontoth.cz/attachments/025_dbinit_stl_views.txt.
Tiskni
Sdílej:
1.3.2008 01:49
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Častým důvodem je původní CLI rozhraní GDB, nicméně to není v současné době jediná možnost.U mě je důvodem to, že 1) je často příčinou pádu programu - při attachu se někdy začnou dít naprosto šílené věci 2) pád programu ho samotného zhavaruje 3) občas když pauznu ladění a chci pokračovat, tvrdí, že nemá proces 4) občas dokonce udělá SIGSTOP sám na sebe
1.3.2008 14:38
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Valgrind ma dva debugovaci moduly. Memcheck se stara o pamet a pak je tady jeste Helgrind, ktery hleda chyby pri praci s vlakny.Valgrind má ještě také cachegrind (využití cache), callgrind (profiling volání) a massif (profiling haldy). Kromě toho umožňuje přidat si vlastní modul. Mám ale pocit, že některé moduly v novějších verzích nefungují (snad helgrind?).
Dobry integrovany debuger ma napriklad Eclipse CDT, ale tam to zase narazi na to ze GDB ve standardu neumi STL.Debugger v Eclipse blbne, stejně tak v NetBeans a Sun Studiu. Občas podivně chcípne, jindy ani nechce spustit program, má problémy při ladění ve sdílených knihovnách atd. Často se musím uchýlit k ladění přímo pomocí gdb.
Valgrind má ještě také cachegrind (využití cache), callgrind (profiling volání) a massif (profiling haldy). Kromě toho umožňuje přidat si vlastní modul. Mám ale pocit, že některé moduly v novějších verzích nefungují (snad helgrind?).Tady se bavime o debugovani a debugovat cachegrindem, nebo massifem si nedokazu moc predstavit
A helgrind byl v posledni verzi opraven (massif kompletne prepracovan).
1.3.2008 16:14
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
Tady se bavime o debugovani a debugovat cachegrindem, nebo massifem si nedokazu moc predstavitJá jsem to uvedl hlavně pro úplnost - nicméně například zbytečné zdlouhavé prodlévání ve funkcích může být způsobené nějakým bugem, proto je callgrind důležitým debugovacím modulem. Podobné příklady by se daly najít i u zbývajících modulů, byť u nich jde hlavně o výkon.
A helgrind byl v posledni verzi opraven (massif kompletne prepracovan)To je dobrá zpráva
Škoda, taky mi připadal dost dobrý, když jsem si ho zkoušel. Ale hluboký přehled o nich nemám, to přiznávám. 
) Každopádně to je asi sexy fíčura. Nenaportuje to někdo na AMD64?
Nenaportuje to někdo na AMD64?Třeba Kyosuke?
To už by možná mohlo být jenoddušší udělat jeden malý čistě 64b, ne abych se tohle snažil číst a upravovat. 64b ABI je hezky popsané, na DWARF-2 je taky nějaká dokumentace... Otázka ale je, jaký by to pro mě mělo smysl. A už vůbec nepočítej s tím, že by to podporovalo C++. Asi bych se tím naučil hodně o střevech, ale nevím, co víc bych tím získal. Navíc předmět "Psaní debuggerů 1" jsme ve škole neměli. Hele, až jednou budu vědět, že příštích pár let nebudu mít nic lepšího na starosti, tak se ozvu.
Jak dlouho to tam je?
limit co unlimited (resp. aj cely nazov coredumpsize)
a dalsi frontend Grand Unified Debugger
a verze 1.5
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
1.3.2008 22:07