• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    FLEGMA: Ten eclipse frontend mel teda jeste loni pomerne dost much. Kdykoliv sem tim tahal nejaky slozitejsi veci s templatama, tak spadl/ukazoval kraviny. Takze sem skoncil u gdb v terminalu. (Ani nevim ze to ma vlastni debugger, takze nemuzu soudit).

    A Pisa je vtipnej typek, kdyz sem mel prednasku o tom jak se dela VFX do filmu, tak se mne pak ptal na pouzivanej software, byl prekvapenej ze tam neni nic open source a vesmes mne zacal presvedcovat ze proprietalni software je neudrzitelnej a melo by se prejit na open source. Coz mi u softu kterej ma hrozne slozitej vyvoj a velmi omezeny pouziti prislo vtipny :-)
    FLEGMA
    FLEGMA --- ---
    XCHAOS: A remote debug je jako nejakej vyssi luxus v cecku ? Teda to musite trpet :-)
    FLEGMA
    FLEGMA --- ---
    XCHAOS: Taky to nemusis pouzivat oldschoolove v terminalu, i kdyz videl jsem experta ze stary skoly, co s tim fakt umi (Pavel Pisa z FELu http://cmp.felk.cvut.cz/~pisa/ - je to magor v dobrym slova smyslu, spoluautor GCC, C/Linux/elektro guru) a debugoval pomoci milionu klavesovejch zkratek snad rychlejc nez ja normalne v IDEcku.

    Na ty mensi a jednoduchy veci nebo jednorazovky (ca kod na jednu obrazovku) asi okej bez debugu, jinak bych pouzil eclipse, ma frontend pro gdb aj interni debugger. Driv jsem ladil kod v Borland C++, ale to bylo na widlich a uz je to asi mrtvej produkt.

    Pro me je debug primo soucast vyvoje (pisu teda v jave), JVM ma hotswap, coz mi umoznuje si za behu do aplikace dopisovat kod. Na vetsi zmeny, ktery hotswap nezkousne nebo na reload konfiguraku ruznejch frameworku, mam JRebel, bez nej si uz serverovej vyvoj nedokazu predstavit. Spori to spoustu casu, protoze nemusim kvuli kazdy drobnosti otacet aplikac.
    XCHAOS
    XCHAOS --- ---
    DANIELSOFT: jak říkám, já si nějaký čas hrál s xwpe a rhide. pochopitelně po zkušenostech s omezeními v DOSu se mi hrozně líbilo, že můžu krokovat třeba i síťovou aplikaci běžící na serveru... moje kritika se týkala právě méně než nulové uživatelské přítulnosti čistého gdb :-)

    _BENNY: já to úplně chápu... současně ale nevyvíjím komerční aplikace, od kterých bych šířil jen binárky, a podobná situace se u mě neděje moc často. popravdě... trochu něco jsem v posledních pár letech programoval, tedy nejen v C - ale nejčastější způsob komunikace s klientem/uživatelem byl vždy ten, že jsem si vyžádal dodání vstupních dat, které daný problém dokázaly reprodukovat (a tady jsem tedy dokonce byl nucen i hledat chyby po jiných, párkrát). klienta, která dodá coredump, si sice představit umím... ale prostě žádné takové kšefty teď nemám.
    DANIELSOFT
    DANIELSOFT --- ---
    tak kdyz si clovek nad "gdb" nainstaluje "ddd", tak je to o neco pristupnejsi a pohodlnejsi - a pritom clovek neprijde o moznost zadavat primo do gdb commandy, pro ktere v ddd neni gui cudlik
    _BENNY
    _BENNY --- ---
    ono treba kdyz ma clovek pruser nad hlavou a nasranej zakaznik je schopen dodat pouze crashdump, tak veci jako gdb nebo windbg docela uvita. i kdyz to prostredi je fakt desny, zaplatpanbuh za nej :)
    POTRAT
    POTRAT --- ---
    XCHAOS: ja teda s gdb pracuju skoro kazdej den a nemuzu si ho vynachvalit ;)
    XCHAOS
    XCHAOS --- ---
    _BENNY: ale kdo tady mluví o "zanevření"... spíš jsem už dlouho nevyvíjel tak rozsáhlý projekt, který by debugování potřeboval.

    s gdb se pracuje opravdu dost blbě - to je celé, co jsem tím chtěl říct.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: A prozenes to alespon valgrindem, treba?
    _BENNY
    _BENNY --- ---
    XCHAOS: drasticke opatreni je zanevrit na techniky debuggingu kvuli jednomu gdb. hranicici s omezenosti :)
    XCHAOS
    XCHAOS --- ---
    REDGUY:
    _BENNY: trochu jinak :-)

    pod DOSem jsem používal td286 (s td386 byly nějaké problémy s ovladači v reálném módu či co, už si to přesně nepamatuju, DOS byl hrozný bastl). pod Linuxem mi to chybělo, tak jsem zkoušel wpe/xwpe a rhide, což mělo oboje nějaké bindingy na gdb a šlo tam taky krokovat

    párkrát jsem vyzkoušel gdb přímo v textovém režimu, ale tento zážitek se mnou otřásl a hluboce mě vnitřně poznamenal. takže od té doby se snažím, abych věděl, co se v mých programech děje a proč nefungují, a nebylo potřeba podstupovat tak drastická opatření.
    REDGUY
    REDGUY --- ---
    XCHAOS: Znamena to, ze tvoje programy neobsahuji chyby, takze je nemusis debuggovat? A jak velke programy tinhle stylem pises?
    ANT_39
    ANT_39 --- ---
    XCHAOS: tak princip debug informace chápu
    Ok, nevedel jsem, na co se ptas. Jinak je to proste cteni debuginfa, no. Vetsinu zajimave prace odvadi libdwfl, ktery resi kam v pameti se co namapovalo, hleda oddeleny debuginfa, prepocitava adresy, atd. Ta reflexni knihovna samotna je jen pomerne tenky wrapper kolem toho, dohromady to moc nedela.

    Jinak {,eu-}readelf -w umi Dwarf dumpnout v lidsky citelne podobe, tak se clovek muze podivat co jak vypada, jestli ho to zajima. Je to takovy XML pro popis struktury binarek.
    _BENNY
    _BENNY --- ---
    XCHAOS: znouzectnost
    XCHAOS
    XCHAOS --- ---
    _BENNY: asi záleží na tom, co programuješ a jakým stylem. jistě sis všiml, že já se dost snažím o používání už oddebugovaných "design patterns", že jo... nikomu to necpu, ale faktem je, že dnes mi kód, který se přeloží, taky ve většině případů i běží (jistě... najdou se vyjímky...)
    _BENNY
    _BENNY --- ---
    bez debuggeru bych dnes ani nevstal z postele
    XCHAOS
    XCHAOS --- ---
    ANT_39: tak princip debug informace chápu - víceméně, minimálně to umím to odstranit příkazem strip :-) pár experimentů jsem dělal i s gdb (ale víceméně, přechod z DOSu pod Linux pro mě znamenal, že jsem se odnaučil debuggery používat - a místo toho do svých programů vkládám různé debugovací reporty.. ale to není podstatné)

    já jsem právě z toho odkazu pochopil, že It works by interpreting Dwarf debugging information stored at the binary itself.. V podstatě nic proti tomu - jen že je to ještě šílenější, než moje skromné pokusy přiblížit použití Céčka vyšším jazykům :-)
    ANT_39
    ANT_39 --- ---
    XCHAOS: Ladici informace se k binarkam pribaluji, aby debugger umel interpretovat pametovy obraz procesu, protoze v nativnich jazycich jsou jinak vsechno plocha data, kde nepoznas co je co. Aby debugger dokazal ty data interpretovat, potrebuje spoustu informaci: mapovani instrukci na radky kodu, informace pro odrolovani stacku (aby ti mohl ukazat, kde ti to spadlo), informace o jednotlivych funkcich a typech, o tom, kde je ktera promenna v jednotlivych okamzicich sveho zivota (v registru, v pameti, nebo vyoptimalizovana, a jeji hodnota se da spocitat takhle, atd.) Velike lehkotonazni variantou tehoz je tabulka symbolu. Runtime to normalne k zivotu nepotrebuje, je to informace pro debugger (a trasovatka atd.) Kdyz binarku stripnes, tak se to vsechno odstrani, a na beh to nema vliv.

    Tu samou informaci muzes samozrejme pouzit i zevnitr procesu samotneho, k reflexi, i kdyz je to divnost a osobne nevim, ze by to nekdo delal. Kdyz binarku stripnes, tak to prestane fungovat.

    (Vetsina linuxovych dister shipuje binarky stripnuty, a ladici informace se dodavaji v -debuginfo balicich. libdwfl tenhle model podporuje, akorat by potom holt balik musel zaviset na svem vlastnim debuginfu.)
    XCHAOS
    XCHAOS --- ---
    ANT_39: jako mě to celkem zaujalo, že runtime pracuje s nějakými debug informacemi v binárce. mohl by si stručně popsat, jak to funguje a k čemu je to dobré?
    ANT_39
    ANT_39 --- ---
    XCHAOS: Pripominam, ze jsme se k tomu dostali pres VPATH make. To, ze jsem to shodou okolnosti pouzil v obskurni knihovne, je prave jen shoda okolnosti. Rozhodne to neni reakce na nic. Btw, linkoval jsem to cca pul roku zpatky vedle v C/C++ klubu.
    Kliknutím sem můžete změnit nastavení reklam