[PATCH] fix test for vfork function
vapier at gentoo.org
Fri Apr 27 04:58:33 UTC 2012
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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the uClibc