Hacker News Reader

Comment by taviso | Hacker News Reader

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`.

View on HN

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.

Guilty as charged — I have never used GDB for anything but that, and I have never used awk for any other function than to select columns.

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 (!) :

    gdb --batch-silent -ex "attach $PPID" -ex "call (int)bind_variable(\"X\",\"$X\",0)"

I confess that I use this trick in my shell scripts more than strictly necessary, just for fun.

That sounds both useful and horrifying. Do you use this for CI scripts? That's where I've needed this kind of functionality.

Never (yet) in production. I just use it for personal silly scripts, like changing the background color of my running xterms, and things like that.

And you can make gdb send program output to a different terminal with the --tty option if you don't want program output to mess up your gdb windows.

Thanks! I know quite a few gdb tricks but I didn't know about this one, which seems quite useful if you need to debug an interactive console program.

> 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.

Something something running GDB inside of GDB TUI…

> 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).

I find close and reopen the TUI to be the only fix. A PITA for sure, but the only way I can get it to redraw correctly. Will try ctrl+l next time.

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.

Tavis, it would be great to see a screencast from you using gdb.

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.

https://frida.re/docs/javascript-api/

https://twitter.com/taviso/status/1336693403510140929

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.

https://frida.re/docs/home/

Might be a case of outdated documentation/website: https://frida.re/news/2019/05/15/frida-12-5-released/

Interesting, it looks like there was a move from V8 to QuickJS more recently than that: https://frida.re/news/2020/10/28/frida-14-0-released/

EDIT: and then the default moved back in https://frida.re/news/2020/12/01/frida-14-1-released/

It supports both, and they've switched back and forth on what the default should be. They also supported duktape in the past.

I always use v8, because it has better compatibility with libraries and tools.

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.

This is gold. Thank you.

Give it a try, but stick to vanilla gdb tui mode. It's worth learning.

Reply on news.ycombinator.com