From: Heiko Carstens <heiko.carstens@de.ibm.com> vfork support for s390/s390x. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> --- diff -purN a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def --- a/usr/klibc/SYSCALLS.def 2006-06-07 09:44:33.000000000 +0200 +++ b/usr/klibc/SYSCALLS.def 2006-06-07 13:01:54.000000000 +0200 @@ -28,7 +28,7 @@ void _exit,exit::_exit(int) ; A lot of architectures need architecture-specific vfork ; stubs, due to the no-stack requirement. These are the ; architectures which don't. -<alpha,m32r,ppc,ppc64,sh> pid_t vfork() +<alpha,m32r,ppc,ppc64,sh,s390,s390x> pid_t vfork() <sparc,sparc64> pid_t vfork@forkish() #endif <!alpha> pid_t getpid()
Heiko Carstens wrote:> From: Heiko Carstens <heiko.carstens@de.ibm.com> > > vfork support for s390/s390x. >s390(x) doesn't actually use the stack as part of its normal syscall stub? -hpa
Heiko Carstens wrote:> From: Heiko Carstens <heiko.carstens@de.ibm.com> > > vfork support for s390/s390x. > > Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> > --- > > diff -purN a/usr/klibc/SYSCALLS.def b/usr/klibc/SYSCALLS.def > --- a/usr/klibc/SYSCALLS.def 2006-06-07 09:44:33.000000000 +0200 > +++ b/usr/klibc/SYSCALLS.def 2006-06-07 13:01:54.000000000 +0200 > @@ -28,7 +28,7 @@ void _exit,exit::_exit(int) > ; A lot of architectures need architecture-specific vfork > ; stubs, due to the no-stack requirement. These are the > ; architectures which don't. > -<alpha,m32r,ppc,ppc64,sh> pid_t vfork() > +<alpha,m32r,ppc,ppc64,sh,s390,s390x> pid_t vfork() > <sparc,sparc64> pid_t vfork@forkish() > #endif > <!alpha> pid_t getpid()More strongly... does the s390(x) really not use the stack at all, *including for the return address* for the standard syscall stub? vfork is forbidden from using the stack above the level of the stack frame of the *calling* function. This means, for example, that x86-64 need custom stubs, even though the only thing it uses the stack for normally is the return address. -hpa
> >>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...
Heiko Carstens wrote:> > 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...Oh bloody hell. I figured -x c++ should have worked *FOR THE PREPROCESSOR*... dropping it should be fine, too, unless gcc is really really old. This is probably a case for using $(cc_option) or something. -x assembler-with-cpp is liable to have platform-specific bugs, since assembly comment syntax varies by platform. -hpa