stackoverflow上关于gdb attach一个很好的回答

原文地址

This is a classic problem that people have with gdb. It’s so common that you’d think it would have a handy name!

There are a few solutions to the problem, some time-tested and some relatively more experimental.

If the program to debug (in gdb lingo, "the inferior") is long-running -- for example, a GUI or a server of some kind -- then the simplest way is to just run the script, wait for the inferior to start, and then attach to it. You can attach using the PID, either with gdb -p PID or using attach PID at the gdb prompt.

If the program is short-lived, then another classic approach is to add a call to sleep early in the program's startup; say as the first line of main. Then, continue with the attach plan.

Those are the classic ways. But now let’s talk about the more fun stuff.

gdb has a multi-inferior mode, where it can debug multiple processes at once. This mode, IME, is still a bit fragile, but I’ve had some success with it.

First you put gdb into the correct mode:

set detach-on-fork off
set non-stop off
set pagination off

(If you have an older gdb you will also need set target-async on).

Now you can debug the shell, something like:

$ gdb --args /bin/sh /path/to/my/script
(gdb) [… set the mode as above …]
(gdb) break some_function_in_my_inferior

Now run should start the script, and automatically attach gdb to each child process that’s created; eventually stopping at the breakpoint.

There’s still one more way. A long time ago, there was a kernel patch to add “global breakpoints”, plus a gdb patch to work with this feature. As far as I know, none of this was ever merged. But, I wrote a variant in my gdb helpers project.

There is a new command there called preattach. What it does is use SystemTap to watch for an exec of a specified program; then it pauses this program while gdb attaches to it.