Re: _syscall2 in PIC code on ix86

From: Keith Owens (kaos@ocs.com.au)
Date: Sun Jan 16 2000 - 19:58:57 EST


On Sat, 15 Jan 2000, Chris Noe wrote:
> On 14 Jan 2000, H. Peter Anvin wrote:
> > We probably should add a set of macros that include PIC support
> > (_syscallX_pic)... it seems to me the obvious way to deal with this
> > seems to push/pop %ebx around the syscall.
> That sounded easy enough to accomplish that I went ahead and did it;

Please do not change the kernel to add _syscall_pic code, it is
unnecessary bloat. It is a userspace problem which needs a userspace
solution. I have these working defines for syscall_pic, but they
should not go in the kernel.

#define _syscall1_pic(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
long __res; \
__asm__ volatile ("pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" \
        : "=a" (__res) \
        : "0" (__NR_##name),"g" ((long)(arg1))); \
__syscall_return(type,__res); \
}

#define _syscall2_pic(type,name,type1,arg1,type2,arg2) \
type name(type1 arg1,type2 arg2) \
{ \
long __res; \
__asm__ volatile ("pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" \
        : "=a" (__res) \
        : "0" (__NR_##name),"g" ((long)(arg1)),"c" ((long)(arg2))); \
__syscall_return(type,__res); \
}

#define _syscall5_pic(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \
          type5,arg5) \
type name (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5) \
{ \
long __res; \
__asm__ volatile ("pushl %%ebx; movl %2,%%ebx; int $0x80; popl %%ebx" \
        : "=a" (__res) \
        : "0" (__NR_##name),"g" ((long)(arg1)),"c" ((long)(arg2)), \
          "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5))); \
__syscall_return(type,__res); \
}

These work - but glibc 2.1.x already has a standard PIC compatible
syscall(). Since this problem has only just arisen it is not a common
problem. Affected users (at the moment it is just me) can use glibc
2.1.x, a perfect userspace solution to a userspace problem. Using
glibc will also give cross platform compatibility, or is somebody going
to define and maintain _syscall_pic in the kernel for every arch,
including the ones that are not in the standard kernel tree?

What about users not running glibc 2.1.x? The code that needs special
PIC syscalls must be able to run on 2.2 and even 2.0 kernels, all of
which lack PIC syscalls. Either way the userspace code needs a
fallback. Use glibc syscall(), use internal definitions or give up, in
that order.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:14 EST