Some quick notes on debugging programs like Git with GDB.

Git is subprocess-heavy: many of the original scripts to implement porcelain commands orchestrated subprocesses, and vestiges of that remain throughout.

Unfortunately, that makes typical debugging interactions challenging:

λ gdb git merge --autostash
(gdb) b do_stash_apply
(gdb) run

and the git-stash subprocess never gets debugged, because GDB detaches from it when it gets forked!

It seems that the incantation to make Git step into subprocesses (without requiring too much juggling) is something like:

set detach-on-fork off
set schedule-multiple on
set follow-fork-mode parent
set non-stop on
set target-async on

Now, in my GDB 17.2, follow-fork-mode=parent is the default and target-async is now called mi-async, so adjust accordingly.

This way, we can set the breakpoint, run, and then when stopped say info inferiors and inferior <n> to change to the subprocess that hit our breakpoint. Great!

But, I can’t think of a good way to package this up… and I previously had to keep referring to the StackOverflow answer when time would pass between using these options (I have a hard time internalizing all their names as “magic subprocess mode”). Worse, it seems GDB turns history off by default?

(gdb) show history
history expansion:  History expansion on command input is off.
history filename:  The filename in which to record the command history is "/home/benknoble/.gdb_history".
history remove-duplicates:  The number of history entries to look back at for duplicates is 0.
history save:  Saving of the history record on exit is off.
history size:  The size of the command history is 256.

So I suppose I’ll be configuring GDB shortly to save history, and maybe there’s a good way to wrap the above settings?

Aside: Missing auto-load script

If you see

⚠️ warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts

you need to use the Rust GDB wrapper (typically rust-gdb) or ignore the warning if you don’t plan to debug Rust code.

Categories: Blog