Debugování v Linuxu (GDB)

1.3.2008 01:41 | Přečteno: 5039× | Programování

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ů.

Spuštění GDB

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

Nápověda GDB

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.

Začínáme degubovat

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 a watchpointy

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.

Krokování programu

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í a zápis proměnných

Č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 a GUI

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.

Podpora pro C++

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.

       

Komentáře

[Luboš Doležel (Doli)]

Č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

[Let_Me_Be]

A debugujes necim jinym? Ja pouzivam jeste valgrind, ktery je sice schopen vypsat mnohem relevantnejsi informace, ale to je trochu jiny styl debugovani.

[trekker.dk]

Valgrind není debugger v pravém slova smyslu - ano, můžeš v něm najít některé chyby (ty, které se týkají práce s pamětí), ale to je víceméně všechno (uznávám, není to málo)

Bohužel bych řekl, že dobré vývojové prostředí, které by zahrnovalo kvalitní debugger, v Linuxu zatím chybí. Gdb sice v některých situacích poslouží, ale pokud to srovnám třeba s Delphi, tak kam se hrabe.

[Let_Me_Be]

Valgrind ma dva debugovaci moduly. Memcheck se stara o pamet a pak je tady jeste Helgrind, ktery hleda chyby pri praci s vlakny.

Dobry integrovany debuger ma napriklad Eclipse CDT, ale tam to zase narazi na to ze GDB ve standardu neumi STL.

[Luk]

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.

[Let_Me_Be]

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).

[Luk]

Tady se bavime o debugovani a debugovat cachegrindem, nebo massifem si nedokazu moc predstavit

Já 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

[Kyosuke]

Docela zajímavě jako nezávislé nebuggery vypadají edb-debugger a UPS. Obzvlášť na UPS jsem viděl jen samou chválu, ale poslední update je čtyři rok starý a 64b verze není a už asi ani nebude. Š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.

[Kyosuke]

Vzpomínám si z UPS na jednu fíčuru - obsahuje interpret ANSI C a umožňuje klidně i do breaknutého programu "dopsat" kus kódu a UPS se už postará, aby se spouštěl ve správnou chvíli - není třeba nic rekompilovat, restartovat, prostě nic. Nejspíše to má nějaká omezení, třeba proměnné vyoptimalizované fuč to nemusí vidět, ale zase je možné, že v takovém případě to začne intepretovat celou funkci. (Co to dělá s inliningem, to nevím, ale zase bych nečekal, že se inlining a ladicí informace sejdou v jedné binárce, má-li člověk rozum. ) Každopádně to je asi sexy fíčura. Nenaportuje to někdo na AMD64?

[Käyttäjä 11133]

Nenaportuje to někdo na AMD64?

Třeba Kyosuke?

[Kyosuke]

Hmmm, to bych si moc netroufal. 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.

[Libor]

Že to má něco víc než CLI jsem vůbec nevěděl Jak dlouho to tam je?

[qk]

O tom vic nez CLI sem taky nevedel, tak pouziv cgdb (n-curse frontend) a ten ma jeste par jinych vyhod, takze ho asi stale budu uprednostnovat.

[disorder]

no, malokedy hodnotim, ale toto bolo prijemne prekvapko

BTW v zsh limit co unlimited (resp. aj cely nazov coredumpsize)

a dalsi frontend Grand Unified Debugger

[filbar]

Jéé Joomla a verze 1.5

[Josef Kufner]

Doporučuju ddd. Umí toho kopec, konzole gdb tam je taky a hezky to kreslí datové struktury.