Daniel Jalkut wrote :
I noticed in the documentation that for vfork in particular, because it allows the child process to take over the parent's address space until exec'ing, the follow-fork may not be very helpful.
You're wrong : the child process did really not use the parent adress space. And even if it were true, gdb cannot follow both process at the same time, it must choose to follow the parent OR the child. Try to put a breakpoint just after a vfork, you'll see that gdb only break in the parent process (in the default configuration).
If you use fork, the whole parent memory is copied. If you use vfork, the memory is lazily copied : the system wait until it really need to make the copy, ie if both processes don't write anything in a given memory page, the system won't make the copy, but if one do write something, the system make the copy just before effectively writing things. This use the copy-on-write flag of the paged memory manager.
The only difference between fork and vfork is that vfork is more efficient : for the developer, even when debugging, both functions seem to work the same way.
1:00 PM, Damien Bobillot wrote:
There may also be a problem with the process followed by gdb. When you use vfork, the system create a new process, but gdb may only debug on process at the same. It must choose to follow the parent process or the child process. The default behaviour is to follow the parent process, but you may change it with the gdb "set follow-fork-mode child" command.