[klibc] [patch] s390: vfork support

[Heiko Carstens]

> >>More strongly... does the s390(x) really not use the stack at all,
> >>*including for the return address* for the standard syscall stub?
> >s390 uses registers %r2 to %r6 to pass up to 5 parameters and %r14 for
> >the return address. The result of a function call is passed in %r2.
> >So yes, the vfork call does not use any stack at all.
> 
> OK, cool.  Just checking.  I thought s390 was more register-starved than that.
> 
> On that subject, though, I assume s390[x] is going to need arch-specific code
> (or a stub generator overhaul) to support pselect()?  Or does the kernel
> automatically grab the sixth argument (or seventh if it have sys_pselect7)
> from the user stack (which isn't a bad way to deal with it)?

s390 has two ways to deal with syscalls with six parameters: the old one
is to put all six arguments in a structure and pass a pointer to the
structure with the syscall (see e.g. s390 mmap implementation).
The new one is to put the additional parameters in registers too, that
is %r7 for the 6th argument.
And yes, you're right. We need special arch code for the following syscalls:
sys_futex (not supported in klibc, yet(?))
sys_pselect6
sys_splice
sys_sync_file_range (only on s390 because of the off_t arguments)

Btw.: in usr/klibc/syscalls/Kbuild you just changed:

-                                -ansi -x assembler-with-cpp -E -o $@ $<
+                                -ansi -x c++ -E -o $@ $<

This kills my crosscompiler which worked for ages:
"s390x-ibm-linux-gcc: language c++ not recognized"

Guess I need to rebuild the compiler, but: is this change really necessary?
Until now it was possible to build a kernel without c++ support...