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.
gdb --batch-silent -ex "attach $PPID" -ex "call (int)bind_variable(\"X\",\"$X\",0)"
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.
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.
> 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.
I always use v8, because it has better compatibility with libraries and tools.
EDIT: and then the default moved back in https://frida.re/news/2020/12/01/frida-14-1-released/
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`.