-any GDB
prosimvas, pouzivate nejakej rozumnej front end (staci textovej) ke gdb? nebo sem jedinej kdo s tim kramem zapasi? :)
pokazdy kdyz neco delam v gdb tak me to vlastne sere. asi nejvic:
- pomalost (pracuju s binarkama > 3 giga). jeden blbej preklep, aby gdb hledalo v tabulce symbolu a je pomalu rychlejsi to killnout a zacit znovu nez cekat
- pretty printing je dost casto buggy/nestabilni (jasne, neni primo gdb vina, ale manualne prochazet mapy listu se shared pointrama na stringy... kuuurva!)
- neprehlednost.. furt musim nekde neco psat a zjistovat, misto abych videl rovnou: registry, stack, locals, thready
co mi na textovym gdb chybi:
- pohodlnost pri 'bloumani' kodem. dost casto nevim co vlastne hledam a tak jenom trasuju, koukam, nahlizim do datovych struktur co by mohlo bejt relevantni atp. v tomdle me gdb strasne sere, protoze i s tim pretty printem je dost otrava to hledat. ve vizualku je todle mnohem jednodussi, pac clovek proste napul spi a dela klik-klik-klik....-klikklik a vzbudi se az tehdy, kdyz je neco zajimavyho. uz nejsem mladej thread abych jel porad na 100% :)
co jsem vyzkousel:
- v minimu pouzivam tui a cgdb.. ale uprimne to je jak sedet na zidli bez sedaku
- ruzny graficky frontendy typu eclipse, vscode, seer - vsechny maj tu nevyhodu ze jsou ve finale napojeny na ten gdb/mi interface, kterej je imho vetsi pulka problemu (nevim co presne je na tom spatne, rozchazej se interfacy? nebo s tim ty frontendy blbe zachazej?). prochazeni slozitejsich dat bud vubec nefunguje, nebo se na nej nesnesitelne ceka, neuplny data atp
- par textovych frontentu (neco psanyho v pythonu? zkusim dohledat co to bylo).. problem byla opet stabilita
- lldb - to zkousim ted, reaguje mnohem svizneji nez gdb a to jejich textovy gui je na pul cesty toho co bych chtel
asi sem se na jako gamedev na widlich zhejckal - jak je to celkove takovej kompost mezi operacnimi systemy, tak ten jejich debugger je jak perla na.. tom kompostu :)