gdb je dost dobry pro Ccko ale v pripade C++ dost kulha. Problemy s manglovanim C++ jmen symbolu tu byly roky. Dodnes kdyz v gdb u vetsiho projektu zmacknete 2x po sobe TAB na doplneni jmena fce, tak se gdb zblazni a sezere vam vsechnu pamet.
PS: LLVM vyviji svuj vlastni debuger. Uz se tesim.
Kdysi jsem pouzival nastroje Insure anebo Ratioal. Ty funguji podobne jako valgrind, akorat navic funguji i jako wrapper pro gcc. Tzn. do zdrojaku pridavaji vlastni fragmenty kodu, ktery pak predhazuji gcc. Vysledna analyza beziciho programu je o neco detailnejsi nez kdyby se pouzil valgrind. Bohuzel jejich licencni politika je tak silena, ze uz si to nikdo nekupuje.
+1
A přitom tam jsou jen takový základní věci, ty úlohy nikdy nepřesáhly 150 řádků kódu. Navíc se k těm konkrétním úlohám dělaj i pomocný semináře, kde lidi vedou za ručičku.
Takhle se spolehlivě pozná lempl, kterej je na programování prostě úplně levej. Když tím rutinně prochází i web vývojáři, co C/C++ nikdy před tím v životě ani neviděli...
1) Strace se da pouzit i v multithread modu kdy pri kazdem vytvoreni noveho threadu se vytvori novy soubor s prefixem, ktery si urcime coz v pripade napriklad ladeni java aplikaci je neocenitelne. Dale se mi osvedcilo udelat zakladni filtry na volani ktera konci = -1 a vyselektovat ta dulezita (napr. write, read, send, recv atd).
2) Na pokracovani. ktere se bude venovat systemtap se opravdu hodne tesim, zrovna posledni dobou si s nim dost hraju. Chce to uz mit ale pomerne slusnou znalost jadra, aby clovek dokazal posoudit situaci a napsat takovou sondu ktera mu pri reseni jaho problem pomuze. BTW neexistuje nekde nejaky komplexni graficky strom, ktery by znazornoval zavislost na sobe volanych kernel funkci i s nejakym quick popisem ?
Pekny clanek. Pripomelo mi to doby na vysoke skole, kdy sem presel z linuxu/c na Apple a jejich vyvojove nastroje a zjistil, ze nad low level utilitami z *nix sveta jde postavit uzivatelsky mnohem privetivejsi a srozumitelnejsi sada nastroju na konkretni debugovani, hlavne hledani bottlenecku a leaku (sada Instruments, soucast XCode). Pritom je to interne vsecko postaveno na lldb a DTrace.
Pointa je, ze nastroje jsou k dispozici nesmirne mocne, potreba je nejaka uroven navic, ktera prida uzivatelskou privetivost pro lidi, co se soustredi na vyvoj a nastroje na ladeni chteji mit out of box a bez zbytecnych let detailniho studia.
Jinak celkem souhlas s tím posledním odstavcem. Kdo však nechce léta strávit studováním může použít, některý komerční ladící nástroj pro linux. Takovému člověku pak bude celkem jedno zdali ten nástroj bude poskládán podle unixové filozofie či nikoliv. Ale chápu Vás že je trochu škoda nevyužít takový potenciál, který se zde volně nabízí.
Vtipne je, ze ja sem taky tech penez moc nemel (relativne), kdyz sem nastopil na vysokou skolu (matfyz), tak sem si poridil notebook za 20k, protoze to proste jinak neslo a kdyz my po 4 letech doslouzil, tak sem za 27k presel na macbook pro a zacal jako brigadu vyvyjet pro tehdejsi iPhone 3g (vubec prvni release iPhone OS, pro ktery sly delat aplikace a uz cesta zpet nevedla).
Ale to neresim, resim to, ze sem se pomerne vazne venoval vyvoji pro *nix systemy, napriklad sem dobre ovladal freebsd kernel, jeho filosifoii a rozsireni a v te dobe sem "nahodou" presel pod tehdejsi apple a ten rozdil v pristupu k developerovi a jeho potrebam byl dost znatelny.
To co sem se pokousel zduraznit je, ze apple ladici nastroje nejsou nic jineho, nez proste low end DTrace scripty a LLDB a presto je to o uroven vyssi uzivatelska zkusenost nez pristup pres linuxovou command line, ktera se tu prezentuje a je to v ramci XCode zadarmo. To, ze v soucasnem linuxu srovnatelne nastroje nejsou je ciste proto, ze neexistuje nikdo, kdo by uznal za vhodne, ze takove "vysokourovnove" nastroje stoji za to vytvorit.
No jenom nebyly zmineny lepsi nadstavby jako prave Qt Creator, nebo CLion. Qt Creator je vynikajici a free (as in beer and as in speech). Pokladam ho za najlepsi cross-platformni C/C++ IDE. CLion je placeno.
Eclipse CDT jsem uz dlouho nezkousel, ale jen pro uplnost existuje taky (mnozi HW vyrobci na tom zakladaji nastroje, napr. Freescale v tom ma svuj remote debugger nastroje pro PowerPC platformu, TI a Keil myslim taky pro zmenu pro ARM).
Videl jsem i dalsi dobre IDE, ani jsem je nemel sanci vschny vyzkouset - treba CodeBlocks
Ono i na Linuxu je pár pěkných nadstaveb, možná ne úplně profi v porovnání s komerčními debuggery, ale úplně marné to není. Trošku jsem o tom psal u "konkurence" :-) takže už se nebudu moc opakovat:
http://mojefedora.cz/debuggery-a-jejich-nadstavby-v-linuxu/
http://mojefedora.cz/debuggery-a-jejich-nadstavby-v-linuxu-2-cast/
http://mojefedora.cz/debuggery-a-jejich-nadstavby-v-linuxu-3-nemiver/
http://mojefedora.cz/debuggery-a-jejich-nadstavby-v-linuxu-4-kdbg/
http://mojefedora.cz/debuggery-a-jejich-nadstavby-v-linuxu-5-ladeni-aplikaci-v-editorech-emacs-a-vim/
Pekny clanok, tesim sa na dalsie pokracovanie. Svojho casu som sa hral so SystemTapom. Na Fedore s instalaciou nebol problem na Ubuntu/Debian ano, ak to uz funguje ako sa pise v clanku tak je to super. Spominany DTrace4linux je aktivny? Ma nejake vyhody oproti SystemTap? Inak este existuej aj toto ale pravdupovediac som to nikdy nepouzil takze neviem posudit http://lttng.org/ Bolo by dobre zmienit odkial sa daju nastudovat mena funkcii ktore sa daju vyuzit v proboch SystemTapu (ak to vobec je niekde mozne). Naposledy som videl prednasku chlapika z Fedory a priznal ze dokumentacia je tam nanic, tak neviem ci sa to niekam pohlo. Taktiez neviem ci uz aj priklady na ich oficialnej stranke niesu obsolete (zda sa mi ze ked som ich skusal tak som sa skoncil na IRC a dozvedel sa ze su, ale nechcem tarat.). Tiez by bolo zaujimave ukazat rozne existujuce skripty (napr. para-callgraph.stp neviem ci je aj nieco mimo oficialnych stranok, prip hacky so skryvanim procesov a pod ;) taktiez rozne hacky pre GDB ako zmena file descriptorov procesu + rozne psie kusky s /proc strukturov pamate, LD_LIBRARY_PATH a pod.). Pripadne prepojenie trasovanie python kodu a pod (tusim ze sa SystemTap da volat aj vramci zdrojakov (aj mimo C) nieco ako ipdb.set_trace() ale niesom si isty). Posledna vec: zaujimavy priklad by bol mozno nasadit SystemTap na nejaky open source projekt do ktoreho sa chce clovek pustit ale nevie kde zacat ... SystemTap by mohl prezradit nejaku strukturu projektu call grafy a pod. ale to uz je asi mimo serial. Nieco take je ale je to staticka analyza vid tu http://www.mlsec.org/joern/ Drzim palce.
Na FEI STU Robotika a kybernetika
4. Prednáška procesy, vlákna úvod OpenCL
5. Sockety
6. Komunikačné IPC (rúry, zdieľaná pamäť, rady správ)
7. Synchronizačné IPC (semafory, mutexy, zámky súborov, signály bez hodnoty)
8. Signály s hodnotou a časovače-POSIX aj interný
9. Patchovanie jadra RTAI patchom, konfigurácia jadra a RTAI, kompilácia a inštalácia jadra
10. Moduly jadra 1. Makefile, prvé ko-čka, EXPORT_SYMBOL
11. Moduly jadra 2 (symbol dependencies, ..., inštalácia do /lib/modules/$(uname -r)/misc depmod, modprobe, modinfo a makrá na definíciu autora..., Ukážka ako nerobiť cyklus od 1 do 10^40 obsahujúci printk... Module pre RTAI
12. Autotools na Hello World v C a JAVA, tvorba rpm a deb balíčkov bez zavislistí a repozitárov..
Bohužiaľ majú len jeden Unixový predmet, takže tam musí byť všetko z rýchlika
Hlavne kdy pouzit LD_LIBRARY_PATH a kdy LD_PRELOAD, a ze vrazit cesty ke knihovnam do hlavicky elfu - rpath je dobry napad . Jak se k loadovani knihoven stavi ruzne architektury. No a koho to zajima do hloubky at si precte "Linkers and loaders"
Vychazim z toho co obcas hovado programatorske je schopno vyplodit... a jeste staticky linkovat libc knihovnu, u jeje bejby.