I use vanilla gdb, the secret to the arrow-key problem the author had is they needed to switch window focus. The keybinding is Ctrl-X O, but if you don't want to remember that - and who could blame you - you can use the focus command, e.g. `focus cmd` will get you back to the command window, or `focus src` will get you back to the source window.
The display isn't really buggy, it's just the debugee output messed up the terminal. You can redraw it with ^L, or disable the tui while it's running. You can toggle it with Ctrl-X A, or just `tui enable` or `tui disable`.
I quite like the tui, the windows are configurable (use `show tui` and `show style`), and you can display more than just source, there's also registers and disassembly mode, e.g. `tui reg general`.
GDB is incredibly powerful but it really lacks some good tutorial, and some of its defaults are... questionable.
It's so heavily scriptable and configurable that you could argue that it's almost more of a debugger framework than just a debugger. I would argue that it's almost under-used really, simply because most devs don't realize what it can do besides setting a breakpoint and dumping a backtrace.
A cool thing that you can do with gdb is to change the values of variables in programs that are already running, or calling their functions. For example you can update a variable on your parent shell, e.g., "export" the variable $X to your parent (!) :
> The display isn't really buggy, it's just the debugee output messed up the terminal.
That's clearly a horrible UX bug. The point of a debugger is to debug something which is probably going horribly wrong - having it mess up the debug output is a massive pain.
Clearly GDB could prevent this by intercepting the debuggee and preventing it from overwriting the rest of the screen.
Yes, just nobody has implemented it. It's kind of a pain. Also it brings up the question of whether GDB ought to implement a terminal so you can debug curses applications inside the TUI, which is even more of a pain.
> You can redraw it with ^L, or disable the tui while it's running.
I often run into a problem where switching to TUI after a crash disables local echo for some reason. I can't see my typing and TUI's output is totally busted. CTRL-L doesn't fix this, I have to exit the debugger and run "reset" in my terminal. Does anyone know why this happens or how to fix it without exiting the debugger?
I've even tried suspending with CTRL-Z, running "reset", then resuming gdb. This fixes the shell, but TUI is still busted, even with CTRL-L.
It’s a long shot, but try Ctrl+R. That re-enables local echo after it’s disabled in some scenarios (usually by Ctrl+S when connected to a remote session with the right tty settings).
This is a great tip. My workaround to the arrow-keys issue was to learn the (readline?) shortcuts. ie. C-b/C-f for back/forward, C-e/C-a for end of line / start of line, etc.
I don't think I have any of gdb, but I was just talking about a hobby project using frida! Frida is a tool that lets you inject v8 into any process, then exposes a javascript debugging api, I find it incredibly useful.
Wow, that is very interesting. The docs say it is injecting QuickJS though, not v8?
> Frida’s core is written in C and injects QuickJS into the target processes, where your JS gets executed with full access to memory, hooking functions and even calling native functions inside the process.
Its been years since I needed it...
but my favorite was always the DDD front-end (Data Display Debugger). Really nice X based front-end to GDB. The red hat TUI one wasn't bad either.
The display isn't really buggy, it's just the debugee output messed up the terminal. You can redraw it with ^L, or disable the tui while it's running. You can toggle it with Ctrl-X A, or just `tui enable` or `tui disable`.
I quite like the tui, the windows are configurable (use `show tui` and `show style`), and you can display more than just source, there's also registers and disassembly mode, e.g. `tui reg general`.