Fixing an ancient GDB problem | Hacker News Reader

Fixing an ancient GDB problem

lwn.net

127 pointsnyanpasu6411 comments

gdb has been a rat's nest of difficult code due to a million difficult corner cases (even before you take into account all the crazy oddball systems it supports which just increases the complexity combinatorially). By comparison a program like gcc is conceptually "simpler" since the majority of its code base is devoted to the problem at hand (code analysis and generation).

gdb's codebase been continuously painful for as long as I had to deal with it (about the decade before 2000). And 99.99% of my "dealing" with it has been indirect. Yeoman's work was put in by John Gilmore and Stu Grossman in the early-mid 90s both who somehow managed to avoid burning out. My hat is off to Pedro Alves for not only being willing to work on gdb but to tackle gnarly problems.

Just to be clear, pace Shakespeare, I post to praise gdb, not bury it. A debugger is one of the most complex pieces of systems code possible.

The path to acceptance of patches is not great from my experience.

I made a minor change to a doc, which then was then requested to improve other more general parts of the unwinder doc. I did them and submitted. It got kind of approved but not enough for merge. I tried to ping some time later but the approval of somebody else was needed and I gave up.

This post gave me the nudge to ping again for who might be the approver required.

[1] https://sourceware.org/pipermail/gdb-patches/2022-June/18978...

I admit it was a lot easier when Cygnus was managing the development. Now it's back (AFAIK) in volunteer-land things revert to the mean.

Even at Cygnus to get there I needed to engineer a fork (not just codebase -- we went the other way, but organizationally) which at the time was extremely controversial. Nowadays that model is the default. But gdb has no steering committee.

(To quote myself from LWN) My personal experience with a possibly-related bug: when debugging programs which handle Ctrl+C themselves (like PipeWire and Audacious), pressing Ctrl+C will trigger the app's graceful shutdown process (terminating execution) rather than breaking into the debugger like I want. Is this the same bug, and will the changes to gdb fix this issue?

From the article:

As is often the case, Emacs users present their own special challenges. Emacs uses control-C for its own purposes, and remaps SIGINT to control-G instead. In cases like this, the user almost certainly wants control-C to be passed through to the target. The answer is a GDB command that allows the user to specify which key should interrupt the process and return to the GDB prompt.

I find the expectation that ^C puts me back into the debugging session with the target still alive a bit weird. I'd expect the target to handle it the normal way. If I wanted to temporarily halt the target, I'd use ^Z.

Changes nothing for the bug, of course, since the target could be blocking SIGTSTOP.

SIGSTOP can not be blocked.

PS. ^Z sends SIGTSTP not SIGSTOP.

My bad, there's no O in SIGTSTP.

Here's a life changing tip to avoid this kind of issues with GDB: use the extended-remote mode.

Open two terminals (e.g. in tmux), and in the first one run the GDB server.

    $ gdbserver --multi :5555

In the second terminal, open GDB client or your favorite GDB frontend (this can be used with Emacs or Eclipse or whatever):

    $ gdb -tui
    (gdb) target extended-remote :5555
    (gdb) set remote exec-file /remote/path/to/executable # this exe may be stripped
    (gdb) file /path/to/executable_with_debug_syms
    (gdb) set args --cmdline_for_my_app
    (gdb) run
    ... go ahead with your usual debugging

You should save this gdb script to a file and pass it to gdb (`gdb -x myfile.gdb`) or put it in `$PWD/.gdbinit` (put `add-auto-load-safe-path` in `$HOME/.gdbinit`).

(note: if your gdbserver and client are on the same machine, the file path can be the same for "file" and "set remote exec-file")

The program under debug is forked by the gdbserver process in your 1st terminal window. This should avoid the issue in the article by not multiplexing your debuggee process input/output with the GDB frontend's (in the 2nd terminal window).

Compared to normal remote debugging mode, the extended remote mode can restart the process without restarting the debugger and generally has all the features you have in "normal" local debugging. The downside is that it requires an operating system that can run gdbserver, you can't use extended-remote mode for debugging on bare metal firmware, kernel images etc.

I use the extended-remote mode for all debugging because I don't like the process output being interleaved with messages and prompts from GDB. This interleaving is also pretty buggy, especially with certain frontends (like cgdb). Terminal escaping is often broken, and especially if the debuggee process is something with a terminal UI (ncurses etc), it's just not gonna work.

Naturally, being remote debugging, you get the ability to debug across operating systems and CPU architectures. I have my dev tools on an x86 Linux box, but I regularly debug and test on Windows and ARM devices over the network or serial line. Added bonus: you can upload stripped executables on the target device, and the debug symbols can be on your dev box only. This is a huge advantage if you're working on an embedded platform with a slow connection (UART serial ports etc). You may need to configure search paths (set solib-search-path etc) to get the debug syms for any shared libs etc.

One thing that does not work: GEF and other advanced GDB scripts. Some of their features rely on being a local process and having access to /proc filesystem for that process.

Here's the manual pages for remote debugging: https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.h...

Great suggestion, thanks. I’m sick of the program output constantly screwing up the tui.

Reply on news.ycombinator.com