[PATCH] fix test for vfork function

[Mike Frysinger]

On Thursday 26 April 2012 23:08:36 Rich Felker wrote:
> On Thu, Apr 26, 2012 at 10:50:57PM -0400, Mike Frysinger wrote:
> > > This patch adds a test for __UCLIBC_VFORK_USES_CLONE__ feature
> > > definition which an architecture may define if vfork is implemented
> > > using clone.
> > 
> > err, if your kernel arch doesn't have vfork, why is it defining
> > __NR_vfork ? i.e. the uClibc logic should not require
> > __UCLIBC_VFORK_USES_CLONE__.  it can deduce that itself by saying "if
> > !vfork && !fork && clone".
> 
> I don't think !fork belongs in the test. Implementing vfork with clone
> is better than implementing it as just a duplicate of fork. But I'm
> not sure how having macros for this can be useful at all since,
> whatever syscall is used to implement vfork, it has to be written in
> asm unless it's just a duplicate of fork.

if we've got a C-callable clone(), i think we can implement a C vfork() on top 
of that.  it'd be a tail call, so the semantics of parallel stack usage should 
be the same.

i know ia64 implements vfork() with clone(), but it does it in asm, so that 
doesn't make my case :p.

> (Providing returns-twice
> semantics in the same memory space is not possible without asm, except
> perhaps on some oddball architectures where the return address is
> stored in a register

i don't think storing the return address in a register is that odd.  a CALL in 
the Blackfin ISA stores the return address in the RETS register (return from 
subroutine) and it's up to the callee to save it if need be (via manual stack 
push or the LINK insn).  makes leaf functions faster since there's no touching 
of the stack at all (assuming the code can fit in the scratch registers).

> and the compiler chooses not to use the stack to
> store anything in the syscall wrapper function...

i think that's the point of INLINE_SYSCALL() vs INTERNAL_SYSCALL().  the 
latter expands into inline asm that only does the syscall and doesn't touch 
the stack.

> and relying on that
> is very unsafe since the compiler's behavior could change.)

pray you don't look at _fork_parent() in libc/unistd/daemon.c then :p
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/uclibc/attachments/20120427/1611dbfb/attachment.asc>