41–50 of 77 posts
Earlier quoted context omitted.
What do you use for debugging instead?
Print statements, haha. My code is for linear algebra stuff, so it is pretty much a straight shot through/filling in some RCI loop most of the time, I usually just have to find which OpenMP or MPI barrier is misbehaving.
Are there any easier to use C debuggers than GDB? All I really need to do is watch my variables change with each line.
https://github.com/cyrus-and/gdb-dashboard
There's also Voltron which works with both gdb and lldb (amongst others):
Took me some time to get familiar with it but GDB is well documented and fulfills its duty. It looks ancient but it is powerful. Do not underestimate the power of the print command! And the advanced stuff like revers-debugging, multi-threading (all-stop mode - which is the default - and the non-stop mode), binary manipulation (yep, it is possible), and remote debugging. Nowadays accompanied by stuff like debuginfod.…
> Do not underestimate the power of the print command! Still waiting for it to print the contents of a QList or QString, or pull actual data in cases where I see .
This will do the trick, so long as the compiler hasn't completely elided a value.
It feels like there's scope for the DWARF debug info to make optimised variables debuggable normally but that's probably a pretty hairy problem.
Every time a JITted object file is added using the API, the entire symbol table is sorted. If you have 10,000+ JITted object files as we do - it takes hours to days to weeks to register them all.
We use the Undo time traveling debugger that builds on top of GDB. It's awesome but we are crippled because of the JIT API implementation.
I'd love to see this get fixed - if anyone knows who to talk with about it - drop me a line.
Are there other debuggers out there that are easier to extend ?
Earlier quoted context omitted.
Interesting, the last time GDB hit the front page the consensus seemed to be it was far ahead of all the competition. Having never seriously used a debugger it seems like it’s an opinion to me.
I found the link http://www.radgametools.com/debug.htm . Though it looks like the project has been abandoned https://github.com/ValveSoftware/vogl Taken from their FAQ on that page about "Why make a new source-level debugger?" > To put it bluntly, debugging on Linux is just really bad. We believe it is the biggest roadblock to great software for that platform. Don't get us wrong - debugging on Windows isn't great eit…
Not entirely related, but the other day I wanted to add 6502 CPU (old stuff) support to GDB. The code of GDB is a nightmare to understand. I don't say it's good or bad, I really can't judge. But adding a CPU is scary, at best... Even if there is a supportive community and documentation. Are there other debuggers out there that are easier to extend ?
I've done some minimal poking about in the code; I found its object-orientation a bit hard to grok (just for me personally) but it seemed to be quite uniformly applied so it might well be easier to work with.
The GDB JIT interface implementation is seriously flawed. I love GDB - but this causes me a LOT of grief when debugging clasp (Common Lisp implemented using llvm as the backend https://github.com/clasp-developers/clasp.git ). Every time a JITted object file is added using the API, the entire symbol table is sorted. If you have 10,000+ JITted object files as we do - it takes hours to days to weeks to register them all…
Earlier quoted context omitted.
Even if the rest of GDB remains a mystery to you, you can learn the two simplest and most useful functions: 1) how to create a backtrace, and 2) how to create a core dump. That way you can always send a bug report with lots of detail to somebody else for analysis.
> 2) how to create a core dump This is a PITA under Linux, I figured this out but nor happy I had to look. I wish Linux was like OpenBSD, where you get core files by default. This give me yet another reason to switch to OpenBSD, I only wish some other issues I am having with OpenBSD could get solved.
I've previously configured `/proc/sys/kernel/core_pattern` to generate core dumps by default (and not pipe them to a core dump collection program, which may be useful for error reporting but is rarely what I want).
There's also `gcore` for doing on-demand core dumps.
I wish it were possible to configure core dump behaviour per-process (or something similar).
For background, our dev environments consisted of Windows PCs which we used to ssh (using putty, exceed, etc) into a SPARC/Solaris machine to do all of our actual work. Our tools consisted of vi (not vim), clearcase, and whatever other command line tools were available (good luck asking for anything new to be installed).
At some point, I guess somebody installed GNU tools on the solaris machine because I managed to find gdb while rooting around... which I'd never used before - so I set about learning. It proved to be a huge help. I tried to show it to some of the other engineers, but few seemed interested.