[PATCH] ppc64: fix semtimedop compat syscall

David S. Miller davem at davemloft.net
Wed Mar 23 04:26:27 EST 2005

On Tue, 22 Mar 2005 13:42:44 +0100
Arnd Bergmann <arnd at arndb.de> wrote:

> Right, except for the s390 31-bit pointer extension problem.
> arch/s390/kernel/compat_wrapper.S does very similar stuff, but
> has to do it also for syscalls that have only unsigned or pointer
> arguments.
> The s390 file also handles clearing the upper 32 bits for all
> arguments, because the CPU does not do that automatically, unlike
> ppc64 or x86_64 (don't know about the others).

Ok.  The scheme used on sparc64 (and I was under the impression
that a discussion last year left us with the decision that zero
extending all args by default, then fixing up the differences was
the way to go) is to zero extend all the registers at 32-bit syscall
dispatch, then we have fixups for the sign-extension cases.

Regardless, we can genericize this even with the differences.

> I have an old script that generates the s390 compat_wrapper.S file
> from a header file holding all C prototypes for the compat_sys_*
> functions. Maybe we can find a way to make that generic enough
> for all seven compat architectures.

That's a great idea.  This thing could spit out a set of macros
that an arch-specific ASM stub could end up using.

I'm not saying the sparc64 macros are the greatest, but it could
be a starting point.  So this magic header file your program outputs
might look like:

SIGN1(sys32_exit, sparc_exit, ARG0)
SIGN1(sys32_exit_group, sys_exit_group, ARG0)
SIGN1(sys32_wait4, compat_sys_wait4, ARG2)
SIGN1(sys32_creat, sys_creat, ARG1)
SIGN1(sys32_mknod, sys_mknod, ARG1)
SIGN1(sys32_perfctr, sys_perfctr, ARG0)
SIGN1(sys32_umount, sys_umount, ARG1)

etc.  And then arch/${ARCH}/kernel/compat_wrapper.S looks like:

#define SIGN1(STUB,SYSCALL,REG1) ...
#define ARG0 %o0
#define ARG1 %o1
#define ARG2 %o2
#define ARG3 %o3
#define ARG4 %o4
#define ARG5 %o5

#include <linux/compat_wrappers.h>

Just an idea, maybe you can come up with something
cleaner. :-)

More information about the Linuxppc64-dev mailing list