This is the mail archive of the
mailing list for the glibc project.
Re: A test for vfork
> Mail-Copies-To: never
> Cc: email@example.com
> From: Andreas Jaeger <firstname.lastname@example.org>
> Date: 15 Jan 1999 17:33:30 +0100
> User-Agent: Gnus/5.070069 (Pterodactyl Gnus v0.69) XEmacs/21.0(beta62) (Pyrenean)
> >>>>> Andreas Schwab writes:
> > Here is a test for vfork which should tell you if it is implemented
> > correctly. Especially the generic source linux/vfork.c is unusable for
> > machines that put the return pc on the stack (like ix86). Remember that
> > the stack is shared between the parent and the child, thus any function
> > call in the child will clobber the return pc from vfork of the parent.
> > See the existing implementations under sysdeps/unix for hints.
What machines do _not_ store the return PC on the stack at some point?
Even if the routine called is called through a lazy PLT entry?
I think the best solution is to modify the kernel so that the parent
process does not run until the child process exits or execs. Failing
that, vfork() must allocate a new stack for the child to use
(allocated by the child, if possible) and switch to that.
Geoffrey Keating <email@example.com>