I am using gdb-multiarch version 9.1 on Ubuntu to connect to a qemu-mipsel-static version 4.2.0 running a MIPS application which daemonizes itself with fork(), and which is running the built-in gdbserver. Here is the relevant GDB output:

Breakpoint 5, 0x7f5bb874 in daemon () from ./lib/libc.so.0

The next instruction is jalr to fork

(gdb) si
0x7f5738e0 in fork () from ./lib/libc.so.0

Now we are in fork(), let's check the state of follow-fork-mode

(gdb) show follow-fork-mode 
Debugger response to a program call of fork or vfork is "child".

Everything looks good, let's finish the function and check our return value

(gdb) finish
Run till exit from #0  0x7f5738e0 in fork () from ./lib/libc.so.0
0x7f5bb87c in daemon () from ./lib/libc.so.0
(gdb) p $v0
$7 = 119052
(gdb) # what

The PID indicates we are still attached to the parent process


From the docs:

On most systems, GDB has no special support for debugging programs which create additional processes using the fork function. When a program forks, GDB will continue to debug the parent process and the child process will run unimpeded. If you have set a breakpoint in any code which the child then executes, the child will get a SIGTRAP signal which (unless it catches the signal) will cause it to terminate.

On some systems, GDB provides support for debugging programs that create additional processes using the fork or vfork functions. On GNU/Linux platforms, this feature is supported with kernel version 2.5.46 and later.

Could it be that your kernel version is too low?

You can also try catch fork/vfork/exec commands.

  • Thank you for your reply. It wasn't the kernel version, as it was running on a recent Ubuntu release. Even Ubuntu 4.10 (Warty Warthog), the first Ubuntu released, used a newer kernel than 2.5.4. – user503997 Aug 17 '20 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.