[klibc] unbreak vfork on cris architecture

[Thorsten Glaser]

Hi klibc people,

if someone has to say more on this, please do so. I’m only trying
to explain what I _think_ I learned…


>Begin forwarded message originally by Mike Frysinger:

>> On Mon, Mar 21, 2011 at 10:24 AM, Waldemar Brodkorb wrote:

>>> unfortunately the common vfork implementation, which just use
>>> the syscall function to interact with the kernel, does not work
>>> on the cris architecture. The system call vfork is special, on most
>>> architectures just calling syscall is not enough.
>>> The patch below adds the vfork implementation from klibc.

>> this lacks an explanation as to why vfork is so special on cris.

I think vfork is special on most architectures. Both i386 and m68k
klibc vfork.S files contain this comment:

# vfork is nasty - there must be nothing at all on the stack above
# the stack frame of the enclosing function.

The generic syscall handler probably (klibc’s does) pushes some
register(s), like this:
        push    $srp

Ah, yes. µClibc does this as well:
                 subq    4,sp
and
                 push    srp
so it’s done in both cases of the ifdef.

I think this is because it may directly manipulate things.

>> different calling convention ?  different return values ?  something

I think it’s sort of a different calling-returning convention.

>> your simple implementation is probably incorrect -- errno cannot be
>> referenced directly.

Mh. On the other hand, the manpage says:

     In a multithreaded application,  vfork()  borrows  only  the
     thread  of  control  that called vfork() in the parent; that
     is, the child contains only one thread. The use  of  vfork()
     in  multithreaded  applications,  however,  is unsafe due to
     race conditons that can cause the child  process  to  become
     deadlocked  and consequently block both the child and parent
     process from execution indefinitely.

But if that’s a concern… fix it ☺ Waldemar is an integrator, not
a libc hacker. He found a problem and a WFM-style fix, which at
least improves the situation. By all means, replace the errno
access with a jump to __syscall_error after setting up registers
in a way that routine (from sysdeps/linux/cris/sysdep.S) expects
it; I don’t know cris assembly but it doesn’t look _too_ hard…

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh