Re: getpid after vfork broken in recent glibc

[Daniel Jacobowitz <drow@false.org>]

On Mon, Mar 08, 2004 at 09:40:57PM -0500, Andrew Cagney wrote:
> >Hello,
> >
> >in fork_inferior (fork-child.c), gdb uses vfork () to spawn a child
> >process, and then calls getpid () (within gdb_setpgid) from within
> >that child process, before doing the execve ().
> >
> >With current glibc CVS builds, this doesn't work any more, since
> >glibc caches the PID in thread-local memory, and memory is shared
> >between vfork parent and child.  (In fact, what happens is that
> >all subsequent getpid calls in gdb return the pid of the initial
> >child that was spawned ...)  This causes various breakage.
> >
> >Now, according to this libc-hacker thread:
> >http://sources.redhat.com/ml/libc-hacker/2004-03/msg00014.html
> >gdb's behaviour is actually not standards-compliant, as it is not
> >permitted to call getpid () between the vfork and the exec.
> >
> >Can this be fixed in gdb?
> 
> We might as well simply always use fork -- the "performance" benefit is 
> hardly valid any more (Hmm, perhaps something related to this is why 
> vfork never worked, and hence was disabled, on HP/UX).

Since I went to some trouble to make "shell escape" use vfork when
possible (2003-06-21), I have to disagree with your assumption.  When
GDB is using a good-sized chunk of the RAM on a system, forking
unnecessarily is a real pain.

Given the idiotic definition of vfork, though, I guess we don't have a
choice.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer