4 ms·
The symbol thing sounds useful and is something I cannot comment on, since most often I either debug open source programs that I run myself (so I have the binar
by bennofs 9y ago
The symbol thing sounds useful and is something I cannot comment on, since most often I either debug open source programs that I run myself (so I have the binary with compiled with debug symbols) or there is no source at all for the binary (and so no symbols). But, most of the other things you listed are, IMO, quite easy with GDB:
> view program state
in my experience, your often only interested in a few variables. then, you just run
display var
once for each variable and GDB will show the value of var on every break. There is also `info locals` to show a local variables, and I am pretty sure that you can set it up to run on every break with some simple config (there's probably an extension pack that does it)
> call stacks
almost every enhancement plugin for GDB in python that I know of does this (GEF, voltron, ...)
> unpacked C++ containers
I am pretty sure GDB pretty-prints C++ containers?
This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either.
- ksk 9y ago>This isn't to defend GDB, it cannot do Heap activity or CPU usage or GPU state out of the box and sometimes, a visual interface is nicer. I just wanted to comment on what is possible with GDB, because I was often not aware of that either. Surely then, the difference between whats possible, and whats easy/default out of the box isn't simply "CLIs are hard" ! :) Anyway it seems like we'd agree on most things, so nothing really left to discuss.