Would highly recommend pwndbg. Don’t be fooled by the lack of a GUI app, as this presents much more (useful) information than stock gdb while remaining a TUI. Yes, many of the features are catered to binary exploitation specifically, but as it turns out things like being able to inspect the glibc heap are also useful for tracking down strange allocation patterns.
It's not exactly a frontend, but gef extends gdb with an automatically updated "context" view containing registers, stack contents, disassembly, and source code. It's more oriented towards low-level debugging, but I find it useful regardless.
I like QtCreator's debugger, it's nicely laid out. You don't have to create a QtCreator project to debug with it. You can either start an executable via a dialog or connect to a running program by PID.
Thanks for the suggestion! This is for hobby coding and on a modest laptop. Do you have a fallback open source tool, even terminal only, that is just a frontend for gdb?
I recently used kdevelop just a little bit. Not enough to form a strong opinion about it, but it was decent to use on a 2018 ThinkPad, so it might be a fit depending on how modest you mean, exactly. And the debugger front-end was good for as much as I used it.
I've also got this saved in my notebook about fiddling with stm32. I haven't tried it personally, but it looks very promising for debugging native code, not just cross-debugging:
Ah! That probably means im using it wrong. I like that dlv shows the source code around the breakpoint. Gdb tui kind of does that but then the arrow keys scroll through the source code instead of command history and I started to get confused.
Possibly im looking for a neovim gdb plugin.
Id like to scroll through source code, add breakpoints and then watch variables as I step through.
At some point 9ish years ago I went through every gdb frontend I could find and all of them were terrible besides cgdb (do :set winsplitorientation=vertical).
I do actually miss it when I'm on macOS because somehow lldb is both a worse debugger than gdb and has worse frontends than gdb...
I do too. It has hundreds of different commands and it's hard to find the one that's relevant to my task. Do I just need to read the manual harder (or some other document) so that it'll finally click, or does it just have a poor interface design?
Shorden | 5 hours ago
Would highly recommend pwndbg. Don’t be fooled by the lack of a GUI app, as this presents much more (useful) information than stock gdb while remaining a TUI. Yes, many of the features are catered to binary exploitation specifically, but as it turns out things like being able to inspect the glibc heap are also useful for tracking down strange allocation patterns.
mariusor | 6 hours ago
It's not a TUI, but you could try Seer.
Personally I'm eagerly waiting for the rad debugger to make it's way to linux.
purplesyringa | 2 hours ago
It's not exactly a frontend, but gef extends gdb with an automatically updated "context" view containing registers, stack contents, disassembly, and source code. It's more oriented towards low-level debugging, but I find it useful regardless.
kryptiskt | 6 hours ago
I like QtCreator's debugger, it's nicely laid out. You don't have to create a QtCreator project to debug with it. You can either start an executable via a dialog or connect to a running program by PID.
hugoarnal | 6 hours ago
Mostly I only use the gdb tui. However, when I get annoyed, I end up using gf (then printf debugging...)
hoistbypetard | 7 hours ago
I like Jetbrains. (So Clion for C/C++.)
I used to love ddd, but it's kinda tough to build and use these days (or last time I tried to use it anyway).
[OP] kghose | 7 hours ago
Thanks for the suggestion! This is for hobby coding and on a modest laptop. Do you have a fallback open source tool, even terminal only, that is just a frontend for gdb?
hoistbypetard | 7 hours ago
I recently used kdevelop just a little bit. Not enough to form a strong opinion about it, but it was decent to use on a 2018 ThinkPad, so it might be a fit depending on how modest you mean, exactly. And the debugger front-end was good for as much as I used it.
I've also got this saved in my notebook about fiddling with stm32. I haven't tried it personally, but it looks very promising for debugging native code, not just cross-debugging:
https://github.com/rohanrhu/gdb-frontend
donio | 6 hours ago
I use Emacs and GUD for both gdb and delve but this is probably not helpful unless you are already an Emacs user.
But I am curious what elevates the dlv UI above gdb in your eyes? To me they don't feel that different.
[OP] kghose | 3 hours ago
Ah! That probably means im using it wrong. I like that dlv shows the source code around the breakpoint. Gdb tui kind of does that but then the arrow keys scroll through the source code instead of command history and I started to get confused.
Possibly im looking for a neovim gdb plugin.
Id like to scroll through source code, add breakpoints and then watch variables as I step through.
abbeyj | 2 hours ago
I usually use cgdb (homepage, github). Sadly there have been no new releases for over 4 years and it looks like development has pretty much stopped.
mikejsavage | 25 minutes ago
At some point 9ish years ago I went through every gdb frontend I could find and all of them were terrible besides cgdb (do :set winsplitorientation=vertical).
I do actually miss it when I'm on macOS because somehow lldb is both a worse debugger than gdb and has worse frontends than gdb...
lightandlight | 23 minutes ago
I do too. It has hundreds of different commands and it's hard to find the one that's relevant to my task. Do I just need to read the manual harder (or some other document) so that it'll finally click, or does it just have a poor interface design?