[uClibc]Re: vfork test fail in ppc target

[Colin.Helliwell at Zarlink.Com]

Hi,
Subsequent to Shaowei Dai's reported problem in
http://www.uclibc.org/lists/uclibc/2002-June/005925.html , I am also
posting with a bit more information on this issue.
I am using uClibc version 0.9.15, on a PPC405-based platform, kernel 2.4.17
and when trying the vfork test I get exactly the same results as Shaowei. I
have modified the test to do a "/bin/ps ao pid,ppid,args" instead of an
"/bin/ls", and this gives the following results:

root at 144.168.115.132:~/temp# ./vfork-glibc
Hi.  I'm the child process...
Hello.  I'm the parent process.
  PID  PPID COMMAND
   84     1 -bash
  222    84 ./vfork-glibc
  223   222 /bin/ps ao pid,ppid,args
Child process exited.
Goodbye.
root at 144.168.115.132:~/temp#
root at 144.168.115.132:~/temp#
root at 144.168.115.132:~/temp# ./vfork-uclibc
Hi.  I'm the child process...
root at 144.168.115.132:~/temp#   PID  PPID COMMAND
   84     1 -bash
  225     1 /bin/ps ao pid,ppid,args

root at 144.168.115.132:~/temp#


Notice how the process ID and in particular the parent process ID appears
to be totally messed up with uClibc.

Examination of the glibc source reveals that it doesn't actually attempt to
implement a separate vfork function, it is simply mapped straight to fork
instead. This leads me to believe that either the uClibc vfork
(libc/sysdeps/linux/powerpc/vfork.c) is at fault, or the vfork system call
in the kernel - my guess at this stage would be the latter, though I am not
knowledgeable enough about the kernel/PPC to be able to 'prove' (or fix)
it.

As regards addressing this issue, I guess there's a number of options:
 - If its a kernel bug, either fix it (?) or "un-implement" the vfork
syscall so that the uclibc vfork falls back on fork as it is already
designed to do.
 - Change the uClibc vfork() to only use the fork system call (ie as glibc
does)
 - Force a "#define vfork fork" in the uClibc files that use it, such as
system.c and popen.c

If the fault is in the kernel, then admittedly its there that some form of
fix is required, but it would still be of value if uClibc was 'wise' to
this problem and catered for it.


Colin Helliwell