Názory k článku Gdb pro normální lidi (2)

Jak je to s debuggovanim vicevlaknovych programku?

Jde to docela dobre. Normalne si nastavite breakpoint, spustite to, vlakno, ktere tam dorazi, se breakne a muzete normalne debugovat. Ted nevim presne, jestli se to obcas prepne do jineho vlakna nebo ne.

cha, ovsem funguje to jen kdyz neni potreba bezi sebou synchronizovat vlakna a pod, cili debugovani obecne nedoporucu vubec pouzivat a radeji dat prednost klasickemu vypisovani

Co se tyce vypisovani, mam ty nejlepsi zkusenosti, stejne ale pak ve finalu kontruluji vysledek v gdb, kdyz z logu zjistim kde to padlo.

Jinak gbd umoznuje 'logovani' programu, ja osobne jsem to sice zatim jeste nikdy nepotreboval, ale kdyz si das v gdb 'help tracepoints' dozvis se vice.

Dalsi velice uzitecnou featurkou gdb je prikaz set, ktery umoznuje menit hodnotu zvolene promenne (registru, ...).

Casto pouzivam prikaz watch, kdyz chci, aby se program zastavil pri zmene hodnoty nejake promenne, pripadne kdyz nabyde nejake konkretni hodnoty.
Tenhle prikaz ma jedinou nevyhodu a to je, ze kdyz ho pouzijete na lokalni promenne, tak po opusteni bloku, kde jsou definovany se toto nastaveni zapomene.
Reseni je udelat si break na vstupu do tohoto bloku a nastavit si v nem ten watch jak ho chcete mit.

pouzivam tyhle prikazy
help thread :)
info thread : vypise seznam threadu
thread N : prepne do threadu N
thread apply N command : v threadu N provede prikaz command

nazorny priklad (proces vytvori thread ve kterem je pause() a potom si da taky pause())

Program received signal SIGINT, Interrupt.
0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) info threads
2 process 1081385 0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
1 process 1081385 0xb032a0e5 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) thread 1
[Switching to thread 1 (process 1081385)]#0 0xb032a0e5 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) info threads
2 process 1081385 0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
* 1 process 1081385 0xb032a0e5 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) thread 2
[Switching to thread 2 (process 1081385)]#0 0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) info threads
* 2 process 1081385 0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
1 process 1081385 0xb032a0e5 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) thread apply 1 break main

Thread 1 (process 1081385):
Breakpoint 1 at 0x8048512: file ../src/main.c, line 15.
#0 0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
(gdb) info threads
* 2 process 1081385 0xb032a0e6 in SignalWaitinfo () from /x86/lib/libc.so.2
1 process 1081385 0xb032a0e5 in SignalWaitinfo () from /x86/lib/libc.so.2

Ahoj,

pomoci prikazu 'p' jde volat i funkci. Pokud chcete vypisovat nejake komplikovane datove struktury (a kdovico jeste), napiste si do programu funkci, ktera to udela a pak v GDB dejte:

p funkce (parametry)

Když už se na MFF učíte teď programovat, tak si šmudové nejprve přečtěte, jak má přesně vypadat odpověď WWW-serveru 302.
( 1. má mít BODY, 2. Location v hlavičce má být absolutní.)
Podle toho nejspíš budou i ostatní věci správně tak asi napůl!

To opravdu nevypada hezky. Slova temporarni a breakpoint spolu nekolokuji. Navrhuji nahradit slovo breakpoint slovem brejkpojnt.

budu mirne oponovat :) Prznim slova jen do te miry, abych je mohla napasovat na ceska morfologicka a syntakticka pravidla...tudiz zmena nesklonneho temporary na temporarni je opodstatnena, kdezto pro zmenu breakpointu na brejkpojnt nemam nejmensi duvod.

No a nebylo by nejlepsi to proste prelozit jako se to dela od dob prvniho slovniku? ;) Breakpoint je jasny, tomu se snad ani jinak nerika, ale "temporary" rozhodne nema ekvivalent v ceskem "temporarni". Temporary znamena "docasny" a ja nevidim duvod proc to nepouzit...

Z napsani slova temporarni mam vetsi pozitek nez z napsani slova docasny :)
Je to proste soucast meho stylu, ktery nedelam, abych zaujala, ale proste proto, ze to tak plyne samo.
Vzhledem k tomu, ze v ostatnich cestinskych aspektech jsem na tom IMHO lepe nez typicky autor (jinak bych nedelala korektorku, zejo :)), tak se ty pozitivni a negativni aspokety hezky vyrovnaji a vyleze z toho prumerene citelny clanek :)

No, ja jen ze mi to nebezpecne pripomina zverstva typu "mrtvy zamek" a podobne, jenom opacne. Nakonec by to mohlo vypadat takhle:

Sekundarni a lastalni dil introduktoria do Gdb splni promise z minula. Breakpoint management, prohlizeni variabilii, checking pameti, loudovani coru a tradicne some bullshit bonus... ;)))

Dovolil byc si oponovat: Nejde o pozitek ale o to, ze to tak je v originalnim anglickym manualu: "temporary breakpoint". Jinymi slovy prelozit "temporary" na "temporarni" je napul lenost a napul povrchnost.

Otazka ale pak zni, jestli pisu clanek pro lidi, nebo pro sebe. Az si na tuto otazku odpovim, tak se rozhodnu, jestli budu psat korektne, nebo tak, jak to plyne samo. Vetsina autoru se myslim snazi, aby tech "pozitivnich aspektu" bylo co nejvic, doporucuju nadprumerne autorce totez...

A ja viem daco! Chcete?
Existuje "commands", ktory definuje skupinu prikazov, ktore sa vykonaju, ked sa vykonavanie programu narazi na breakpoint. Asi takto:
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>print prem
>end

A este lepsie to je, ked poslednym prikazom pred 'end' je 'continue'. Potom mozem napriklad dostat vypis premennych pre vsetky iteracie cyklu bez toho aby som musel skutocne program prerusit

Autorčino krkolomné "define dojed" se dá elegantně nahradit standartním příkazem "until". Dále by bylo dobré definování podmínky pro breakpoint "condition".

Téma dobré, zkracování je (bohužel) horší.

Vida, tak jsem se zase neco noveho naucila...:) Ale vzhledem k tomu, ze krkolomna dojizdeci funkce pochazi z konfiguraku nejmenovaneho *opravdu* dobreho programatora, myslim, ze tam urcite bude nejaky figl :)
Jinak, protoze se tohoto dobreho tematu za ta leta nikdo nechytil, myslim, ze lepsi neco nez nic. Oni vsichni akorat kecaji, co je blbe, ale napsat sami clanek, to ne.
Mas toho vic, co tam nebylo? Nebo neco jineho zajimaveho? Das to do kupy? Tak sem s tim!

Dobry programator != dobry debuggerator :-)

Navic *opravdu* dobri programatori debugger prece vubec nepotrebuji ;-)))

OK, kdyz uz tady mam hloupe reci, tak clanek dodam...

Ano, skutecny programator pise ve strojaku a je neomylny, neco mezi Mirkem Dusinem a Spidlou ;>

Mas tam chybu. :-))

(Dobry programator != dobry debuggerator)||(Dobry programator == dobry debuggerator)

Podle toho, cos napsal ty, by to znamenalo, ze kdyz je nekdo dobry programator, pak nemuze byt dobry debuggerator

tikaz zpracovani ze neni dobre. Zacit hned v prvnim dilu s gdbinit neni nejlepsi.

S gdb delam uz nekolik let a stale se jeste ucim. Nena[adlo mne psat o nem clanek, protoze je se jeste nepovazuji za jeho znalce. Proto mne prekvapilo, ze nekdo s jeste horsimi znalostmi se do toho pustil.

Nechci to zehlit za sebe, ale obecne za vsechny autory - myslim, ze pokud v clanku nejsou primo nesmysly (coz si clovek snadno ohandluje tim, ze to da precist nekomu opravdu dobrymu, kdo je akorat linej o tom psat :), ja to tak delam), je jedno, kdo ho napise, hlavne, kdyz zaplni diry, nekomu to neco da (ano, i taci se tu ozvali) a nekdo schopnejsi se pak treba ozve a tema rozvine (coz se stalo i zde a bude nasledovat pristi tyden).
To vse povazuju za uspech a myslim, ze co se tyce svych primerene prumernych znalosti si na nic nehraju.
Samozrejme budes take vitan, pokud bys chtel ctenarum priblizit veci, co tu nezaznely a myslis si, ze jsou uzitecne.

Mile deti. Nechci Vam kazit radost, ale gdb _neni_ pro normalni lidi. Je jen pro zaslepene Linuxaky jako jste vy. Nic si z toho nedelejte, jednou z toho vyrostete - i ja se kdysi rozplyval nad dokonalosti Vimu, prikazove radky apod. a kdyz me nekdo zacal upozornovat na nedostatky meho milacka tucnaka, zacal jsem mu nadavat (stejne jako vy budete ted nejspis nadavat me a rikat ze jsem klikos).

Ale ted k veci: Kdyz ladim napr. aplikaci v C++, tvorenou nekolika sty zdrojovych souboru, co je efektivnejsi?
a) mit prehledne zobrazeny strom zdrojaku / trid, kod ktery prave ladim, okenko "watch", okenko "variables", stiskem jedne klavesy krokovat, stiskem jine klavesy nastavit breakpoint, ukazanim mysi na promennou se ihned dozvedet jeji hodnotu atd. atd..
b) cucet na text. obrazovku 80x25, kvuli kazdemu prdu tukat nejaky prikaz, lustit textove vypisy, ktere to "vyplivne", videt vzdy jen x radku kontextu kolem kodu ktery ladim atd..

Muze mi nekdo RACIONALNE, BEZ EMOCI vysvetlit PROC povazuje gdb za "vykonny" ladici nastroj? V cem je tahle hruza efektivni? V cem je vykonna? V diskuzi u minuleho dilu psal nekdo o DDD a vypadalo to, ze se skoro stydi za to ze ho pouziva - ostatni mu take hned vysvetlili ze busit v konzoli primo prikazy gdb je produktivnejsi. Pripadne mi, ze vy Linuxaci byste nejradsi ovladali i GIMP z prikazove radky, jako by vizualni zobrazeni a prehledne UI bylo neco fuj, neco pro BFU, klikose a podobny povl, mezi ktery Vy, Linuxaci, prece nepatrite...

Budu rad, kdyz me presvedcite ze se mylim a kdyz mi - opakuji - RACIONALNE, vysvetlite proc je gdb lepsi.

Nereknu Ti, proc je gdb lepsi, protoze jak jsem uvedla, programator jsem spise svatecni. Navic v mem claneku nebylo snad ani slovo o tom, jak je gdb super, powerful, nejlepsi apod., clanek je pro ty, kteri z nejakeho duvodu chteji nebo museji poznat gdb, tem chtel usnadnit zacatky.
Ze mam radsi gdb nez klikose neni zadna moje bezduvodna filosofie - proste textove rozhrani mam rada, protoze je prehledne, protoze vsechno muzu delat na dalku z naprosto libovolneho pocitace, aniz by se pro me neco zmenilo (ale zkus si na dalku po crapovy siti czfree pustit obrazkovej debugger nebo godzillu nebo open ofis), prikazovy konvertidlo obrazku taky ocenim spis nez gimp, protoze mi zkonverti hafo obrazku jednim prikazem (misto otvirani, resize, zavirani...) a kdyz ma clovek nascanovany desitky negativu, ne vzdy ma cas se tim probirat, vsechno jde skriptovat, automatizovat a to je proste bajecny. Kdyz mas na masine klikos konfiguracni tooly, je to bezva, ze se v tom vyznas.
Na *jedny* masine. Ale kdyz se staras jako ja + muj nadadmin o 50 linuxovejch masin, tak je dost drsnej rozdil a) nalogovat se na 50 masin a neco naklikat b) jednim prikazem rozdistribuovat zmenenej konfigurak po cely siti.
Proste to, v cem u me textovy rozhrani a vsechno v nem na cely care vyhrava, je uspora casu, protoze rychlost a automatizace, moznost sedet naprosto kdekoli u libovolne pomaly linky, kdyz moje main masina drepi na Maly strane.
Abych se vratila k tomu debuggeru, kdyz jsem ladila Cursed Gtk, taky jsem to o vikendech a po vecerech delala na dalku
(nemuzu v ty praci drepet *furt*, obcas si chci taky neco uvarit k jidlu), protoze masina na Maly strane to zkompiluje za 2 minuty, domaci za hodinu, no a prufuk domaciho pripojeni je i pri ssh konexi nic moc, vzdalene pustena xkova aplikace ho skoro polozi.
Tak proto gdb.
Nikomu to necpu, uvadim jen sve osobni duvody.

Johanko, asi se pridam k davu tvych obdivovatelu :o) Takhle rozumnou odpoved jsem tu od nikoho necekal. Aby bylo jasno, ja rozhodne nejsem zadny odpurce Linuxu, spis naopak - pod Linuxem programuju a uz 3 roky se tim zivim. Taky umim ocenit, kdyz se daji veci zautomatizovat, kdyz se muzu na server co spravuju pripojit z druheho konce sveta pres ssh a vse co je potreba udelat na dalku.. je spousta veci ktere na Linuxu miluju, myslim si ze umim ocenit silu prikazove radky :) ale vzdycky kdyz prijdu na tenhle server, citim takove.. rozcarovani. Tentokrat jsem to uz nevydrzel a sve srdicko si vylil prave pod timto clankem :) Takze si to neber osobne, klidne to mohl schytat nekdo jiny (treba ten typek co tu kdysi psal o vypalovani a taky vsechno delal pres prikazovou radku a graficke rozhrani ostre odsoudil :) To proste nepochopim... ma zasada je: shell ano, ale ocad pocad :))) Ale to uz jsem off-topic. Mej se!

Víte, ono se poněkud neslučuje se zaměřením tohoto serveru, aby přišel někdo, a řekl, že právě popsaný nástroj je pouze pro šílence, a navrhl místo toho nástroj POUZE pro wokna a POUZE za slušné peníze... Kdybyste raději chtěl zmínit třeba práci s vývojovými nástroji pod KDE, resp. s RHIDE, nebo s (X)WPE, asi by to dalo lidem poněkud lepší pocit než frustraci a znechucení, kterou takto můžete u těch, co preferují Linux do té míry, že hledají nebo vyrábějí ekvivalenty woknových aplikací, jenom aby nemuseli podporovat hegemonii jediné firmy, vyvolat.
Pokud jde o výhody IDE nad (pro vás surovým) GDB z hlediska komfortu práce, musím souhlasit. Pokud však jde o to, že např. potřebuji odladit svou aplikaci na 10ti dalších počítačích, které se liší jak distribucemi tak OS (všechny mají ale společný základ s UNIXem), pak prostě člověk nemá na výběr.
Ale právě v tom, že toto rozhraní je všude prakticky stále STEJNÉ a DOSTUPNÉ (pokud ne přímo jako součást systému, tak alespoň zdarma ve formě tarballu zdrojáku), bez ohledu, zdali stroj je nějaký děda HPsUX (packardi a příznivci UXu prominou), nebo poslední verze chameleóna z Nurnbergu...
Takže, někdo může ty výhody vidět z poněkud jiného úhlu než Vy (tj. komfort není vrchol všeho)... :)

Ja v zadnem pripade netvrdim, ze MS Visual Studio je jedina alternativa. Jen me to napadlo jako ukazka hodne komfortniho debuggeru (a priznavam ze taky jako dobra provokace :)

Kdyz delam pod UNIXem, bohate mi k programovani staci Vim a DDD. Kdysi jsem zkousel ruzna IDE pod Linux, ale vzdy po odpoledni stravenem stahovanim a kompilaci x knihoven na kterych dany program zavisel, kompilaci a testovanim onoho prostredi jsem se vratil zpet k tomu Vimu. Ale na to "Vase" WPE a RHIDE se jdu podivat, diky za tip ;)

Jo, timhle prispevkem si u me Johanka taky brutalne splhla. Chtel jsem reagovat sam, ale predbehla me a lip bych to rozhodne nenapsal.

Tahle Tvoje reakce je taky koser, ale puvodni prispevek mi pripadal vcelku zbytecne konfliktni. Casto se az v delsi diskusi zjisti, ze maji lidi podobny nazor a ze pohled toho druheho neni az tak jednostranny a fanaticky.

Textove rozhrani byva obvykle vyrazne flexibilnejsi. Napr. neni problem ho pres roury propojit s cim zrovna clovek potrebuje. Jiste, nevyhodou muze (ale z principu nemusi) byt nizsi komfort a zpravidla to cloveka nuti si pamatovat dost prikazu nebo parametru. Proto se taky delaji expertni nadstavby -- expertni mysleno ve smyslu expertniho systemu, tedy software, ktery obsahuje a poskytuje jakousi znalost, jako v tomto pripade ddd "zna" gdb.

Nastinena otazka mi pripomina dilema, jestli jezdit Rolcem nebo Jeepem :), osobne bych v lese Rolcem nejezdil :)). A mimochodem i GIMP se da pouzivat z prikazove radky, a to pomijim fakt, ze kdyz nemuzete pouzit gimp, tak jste jeste kolikrat vdecni za format xpm a vim :).

Napisu taky neco o prikazove radce a takovych vecech, i kdyz ne tak pekne jako Johanka.
Samozrejme nemam 80x25, ale 130x35, nebo tak nejak, virtualni konzole, ... Nekdo jiny by treba mel nekolik xtermuv nekolika oknech, to neni dulezite. Take se hodi pomoci mysi prenaset kousky textu mezi programy, ktere o tom ani nevedi -- ja pouzivam gpm, ale X by to take poskytly.
Ale to neni dulezite.
Mam rad vi, bash a podobne veci, protoze mam pocit, ze vstup ke slozitejsim vecem, kdybych je potreboval, je snazsi. Takove "70i-<Esc>" pro vyplneni radky znakem "-" ma svou krasu. Obcas pouziju prikazovou radku k nahrazovani: "'a,'bs/^/%% /g". V bashi pouzivam na prikazove radce casto for-cyklus nebo while cyklus.
V grafickem rozhrani ma clovek jednodussi najit jednotlivost, zmenit ji, ale kdyz by se hodilo usnadnit si zivot takovymto miniaturnim "programkem," clovek se neodhodla, protoze by musel prekrocit barieru.
Take se mi libi, ze kdyz mam pred ocima jen tu informaci, o kterou si explicitne reknu, tak moji pozornost nerozptyluje spousta balastu. (To je ale take argument, proc cist knizky misto koukani na televizi.)
Vsechno ma svuj rub a lic. Libi se mi logicke ovladani vimu pomoci pismenek, nemusim hledat Shift-F11 apod., ale na druhou stranu se velmi casto v mych textech vyskytne nejake to "i" navic.
Podobne je skvele, ze po dvou kratkych clancich Johanky si umim treba vypsat, jak se za behu programu menila promenna x, pricemz me
ale zajimaji jen situace, kdy flagZ byl false. Tohle, nebo nejakou jinou neobvyklou kombinaci, bych ve vizualnim debuggeru delal tezko. Ale dan za tohle je, ze na zacatku se hur startuje: ac jsem kdysi pouzival borlandi Turbo nastroje, na Linuxu jsem se radeji omezil na printf, nez bych studoval dokumentaci, jak krokovat program v gdb.
Proto se ja celkove klonim k mene vizualnimu stylu, pokud se programovani tyce; mozna kdyby mel Pruzkumnik zabudovane KoPeNogramy ;-)
Jsou veci, kde je obrazek nutny, nejen editace obrazku, ale treba i graf jak budou moduly propojeny. Ale tam zase je casto tuzka a
papir mnohem flexibilnejsi nez jakekoli digitalni kreslitko--v digitalnim kreslitku se da udelat finalni verze, je-li nutno ji uchovavat.

Stepan Kasal

Jak jiz bylo zmineno existuji nadstavby (ddd, xgdb/xxgdb z te okynkove casti).
To co bylo uvedeno ve dvou clancich zde zdaleka napostihuje plnou silu nastroje jako je gdb, ale to jiste tusite. Pro kohokoliv kdo s timto nastrojem pracuje je todle prijemne osvezeni, pro ostatni prijemny uvod.
Veci jako je automaticky vypis, watchpoints, save historie promennych jsou to co zapinate po uricte dobe temer automaticky. No nic, diky za zajimavy clanek a diskusi.

Kdyz je dana adresa v /proc/cislo_procesu/maps je a neni rw, tak to jeste neznamena, ze to je kod a ze to nejsou data. Data muzu mit namapovany i RO (napriklad z nejakyho souboru).

BRain

Neni pravda, ze kdyz pustime gdb <program> <core>, tak se muzeme chovat uplne stejne jako kdyby nam program padl primo v gdb.

Kdyz program padne primo v gdb, tak gdbcko akorat odchyti svym handlerem signal 11, program se zastavi a objevi se gdb prompt. Nicmene spadly program porad visi v kernelu (muzete si ho vylistovat v ps) a to znamena, ze jsou dostupne vsechny struktury s procesem spojene, veskere informace v /proc/<cislo_procesu>. Kdyz program naladuju z core, tak "jsem prijel po funuse a mrtvolu uz odvezli" - aneb proces v kernelu neni. Do core se neuklada vse - jen adresni prostor a registry, to znamena, ze z core napriklad neziskam file-descriptory. Kdyz mi program lehne v gdb, mam filedescriptory, pipy, veskere sdileni cehokoliv s ostatnimi procesy atd.

Proto je lepsi, kdyz nam program padne primo v gdb, da se debugovat lepe a radostneji.

BRain

nepouzivejte zadne optimalizace (-O2 -O3) pri kompilaci. napr:

gcc -O2 -ggdb3 -o program program.c

gdb, potom skace v kodu trochu nahodne :-) !!!