Nice! There is already a TUI in gdb albeit not as good looking. For more info, there is a quick talk about it and other niceties that you may not know about: https://www.youtube.com/watch?v=PorfLSr3DDI
There are a lot of these types of tools already in the reverse engineering community (in order of lowest chance of breaking when you throw really weird stuff at it, in my experience):
They also come with a slew of different features to aid in RE/exploit dev, but many of them are also useful for debugging really weird issues.
Also if you don't need all the info these provide or just want to augment them, the tool you are looking for is "hook-stop" which allows you to execute a string of commands every time GDB pauses program execution.
I really like PWNDBG, as it goes. But I am trying to spend more time with the Ghidra debugger, which is ... kind of pants, but it's getting better and it's pretty nice to have everything in one place. :}
I tried to promote gdb-dashboard a few days ago at HN but it did not fly.
gdb-dashbard is different from those reverse-engineering gdb-hacks in that, it is more for normal debugging with a better looking TUI than the default gdb tui interface.
gdb's support for python scripting made all these possible.
Anyone remember Periscope? It was a DOS debugger with the hardware button attached to the NMI pin on the chip to break in even if interrupts are disabled! It was awesome.
Still unequalled if you ask me, although gdb-dashboard comes pretty close.
EDIT: A quick bit of searching yielded a scanned copy of the manual courtesy of the os2museum.com:
Being able to enter a debugger on NMI is great because now you can trigger the NMI from any set of hardware conditions too - you can connect logic gates to the address bus to decode a range of addresses, "and" it with the memory write assert pin or IORQ pin and now you have hardware breakpoints for a machine that didn't originally support it.
Dashboard has been around for a while. It helped me back when I learned GDB for the first time. Though you still have to learn the GDB commands, dashboard makes it a more visual experience. GDB felt clearer and more modern with it. It's better than the built-in TUI in my opinion.
Well that's a masterful stroke. I use GDB all the time not only for userspace but also the kernel. Its always sorta painful though for the exact reason that using tui and getting it to display variables, code, dissasembly, etc tends to require jumping through about 20 commands (usually via a gdb script) to see how the behavior is changing over time.
So, I'm not really sure why it took this long to catch up to the TUI debuggers from the late '80's (ala turbo debugger/etc).
Makes me want to integrate some of these windows with the kernel gdb scripts.
20 comments
[ 3.4 ms ] story [ 56.9 ms ] threadHowever, accomplishing tasks with textual, batch-oriented interfaces seems easier to script, version, and integrate.
A similar project worth mentioning is Voltron, which can decorate your gdb session with accesory windows. (Use tmux for window layout).
No experience with this dashboard but looking forward to trying it.
GEF: https://gef.readthedocs.io/en/master/
PWNDBG: https://github.com/pwndbg/pwndbg
PEDA: https://github.com/longld/peda
They also come with a slew of different features to aid in RE/exploit dev, but many of them are also useful for debugging really weird issues.
Also if you don't need all the info these provide or just want to augment them, the tool you are looking for is "hook-stop" which allows you to execute a string of commands every time GDB pauses program execution.
gdb-dashbard is different from those reverse-engineering gdb-hacks in that, it is more for normal debugging with a better looking TUI than the default gdb tui interface.
gdb's support for python scripting made all these possible.
GDB has also added Python extension support for it: https://sourceware.org/gdb/current/onlinedocs/gdb/TUI-Window...
It will be interesting to see if things like GDB Dashboard benefit from being implemented in this way in future.
Still unequalled if you ask me, although gdb-dashboard comes pretty close.
EDIT: A quick bit of searching yielded a scanned copy of the manual courtesy of the os2museum.com:
https://www.os2museum.com/files/docs/periscope/periscope-man...
Can someone say what the "encrypt+" column to the left of the the Op code is in the screenshot?
So, I'm not really sure why it took this long to catch up to the TUI debuggers from the late '80's (ala turbo debugger/etc).
Makes me want to integrate some of these windows with the kernel gdb scripts.