[PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Markus Gutschke]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

From: Markus Gutschke <markus@google.com>

Gcc reserves %ebx when compiling position-independent-code on i386. This 
means, the _syscallX() macros in include/asm-i386/unistd.h will not 
compile. This patch is against 2.6.15.6 and adds a new set of macros 
which will be used in PIC mode. These macros take special care to 
preserve %ebx.

The bug can be tracked at http://bugzilla.kernel.org/show_bug.cgi?id=6204

Signed-off-by: Markus Gutschke <markus@google.com>

---

[-- Attachment #2: i386-unistd.h.diff --]
[-- Type: text/x-patch, Size: 3029 bytes --]

--- linux/include/asm-i386/unistd.h.orig	2006-03-05 11:07:54.000000000 -0800
+++ linux/include/asm-i386/unistd.h	2006-03-09 14:25:45.000000000 -0800
@@ -326,6 +326,7 @@
 __syscall_return(type,__res); \
 }
 
+#ifndef __PIC__
 #define _syscall1(type,name,type1,arg1) \
 type name(type1 arg1) \
 { \
@@ -393,6 +394,82 @@
 __syscall_return(type,__res); \
 }
 
+#else /* __PIC__ */
+
+#define _syscall1(type,name,type1,arg1) \
+type name(type1 arg1) \
+{ \
+long __res; \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
+	: "=a" (__res) \
+	: "0" (__NR_##name),"ri" ((long)(arg1)) : "memory"); \
+__syscall_return(type,__res); \
+}
+
+#define _syscall2(type,name,type1,arg1,type2,arg2) \
+type name(type1 arg1,type2 arg2) \
+{ \
+long __res; \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
+	: "=a" (__res) \
+	: "0" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)) \
+	: "memory"); \
+__syscall_return(type,__res); \
+}
+
+#define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \
+type name(type1 arg1,type2 arg2,type3 arg3) \
+{ \
+long __res; \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
+	: "=a" (__res) \
+	: "0" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
+		  "d" ((long)(arg3)) : "memory"); \
+__syscall_return(type,__res); \
+}
+
+#define _syscall4(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4) \
+type name (type1 arg1, type2 arg2, type3 arg3, type4 arg4) \
+{ \
+long __res; \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
+	: "=a" (__res) \
+	: "0" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
+	  "d" ((long)(arg3)),"S" ((long)(arg4)) : "memory"); \
+__syscall_return(type,__res); \
+} 
+
+#define _syscall5(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 ("push %%ebx ; movl %2,%%ebx ; movl %1,%%eax ; " \
+                  "int $0x80 ; pop %%ebx" \
+	: "=a" (__res) \
+	: "i" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
+	  "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5)) \
+	: "memory"); \
+__syscall_return(type,__res); \
+}
+
+#define _syscall6(type,name,type1,arg1,type2,arg2,type3,arg3,type4,arg4, \
+	  type5,arg5,type6,arg6) \
+type name (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5,type6 arg6) \
+{ \
+long __res; \
+  struct { long __a1; long __a6; } __s = { (long)arg1, (long)arg6 }; \
+__asm__ volatile ("push %%ebp ; push %%ebx ; movl 4(%2),%%ebp ; " \
+                  "movl 0(%2),%%ebx ; movl %1,%%eax ; int $0x80 ; " \
+                  "pop %%ebx ;  pop %%ebp" \
+	: "=a" (__res) \
+	: "i" (__NR_##name),"0" ((long)(&__s)),"c" ((long)(arg2)), \
+	  "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5)) \
+	: "memory"); \
+__syscall_return(type,__res); \
+}
+#endif /* __PIC__ */
+
 #ifdef __KERNEL__
 #define __ARCH_WANT_IPC_PARSE_VERSION
 #define __ARCH_WANT_OLD_READDIR

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Andrew Morton]

Markus Gutschke <markus@google.com> wrote:
>
> Gcc reserves %ebx when compiling position-independent-code on i386. This 
>  means, the _syscallX() macros in include/asm-i386/unistd.h will not 
>  compile. This patch is against 2.6.15.6 and adds a new set of macros 
>  which will be used in PIC mode. These macros take special care to 
>  preserve %ebx.

But we don't compile the kernel with -fpic...  We might want to, for kdump
convenience at some stage, perhaps.

If we do, it'd be better to simply replace those _syscallX functions with
versions which work in either mode, rather than having two versions.

The syscallX() macros are almost obsolete - it's preferred that code simply
include syscalls.h and call sys_foo() directly.  But there are a few
hard-to-convert places, iirc.

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Markus Gutschke]

Andrew Morton wrote:
> But we don't compile the kernel with -fpic...  We might want to, for kdump
> convenience at some stage, perhaps.

Unless I am really confused, there should be no place in the kernel that 
uses any of the _syscallX() macros. These macros are for the benefit of 
userspace, and they get picked up by and distributed with glibc. They 
just happen to be shipped and maintained with the kernel.

> If we do, it'd be better to simply replace those _syscallX functions with
> versions which work in either mode, rather than having two versions.

That is certainly possible. The new macros work in both modes, but they 
are slightly less efficient than the old macros, if you have access to 
%ebx (i.e. in non-PIC code). If you prefer, we could just remove the old 
macros and unconditionally replace them with the new ones.

> The syscallX() macros are almost obsolete - it's preferred that code simply
> include syscalls.h and call sys_foo() directly.  But there are a few
> hard-to-convert places, iirc.

Are you thinking of the code that jumps through the vdso entry point? 
That is not always an easy option for user-space applications which need 
to remain backwards compatible to older versions of the kernel and of libc.


Markus

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Andrew Morton]

Markus Gutschke <markus@google.com> wrote:
>
> Andrew Morton wrote:
> > But we don't compile the kernel with -fpic...  We might want to, for kdump
> > convenience at some stage, perhaps.
> 
> Unless I am really confused, there should be no place in the kernel that 
> uses any of the _syscallX() macros. These macros are for the benefit of 
> userspace, and they get picked up by and distributed with glibc. They 
> just happen to be shipped and maintained with the kernel.

Nope, there's an int-80-based execve() implemented in
include/asm-i386/unistd.h.  It's called from init/do_mounts_initrd.c
and kernel/kmod.c (at least).

> > If we do, it'd be better to simply replace those _syscallX functions with
> > versions which work in either mode, rather than having two versions.
> 
> That is certainly possible. The new macros work in both modes, but they 
> are slightly less efficient than the old macros, if you have access to 
> %ebx (i.e. in non-PIC code). If you prefer, we could just remove the old 
> macros and unconditionally replace them with the new ones.

I'd be OK with that - the kernel doesn't (shouldn't) care about the
performance of __KERNEL_SYSCALLS__ stuff.  I doubt if glibc is borrowing
the kernel's macros.

> > The syscallX() macros are almost obsolete - it's preferred that code simply
> > include syscalls.h and call sys_foo() directly.  But there are a few
> > hard-to-convert places, iirc.
> 
> Are you thinking of the code that jumps through the vdso entry point? 
> That is not always an easy option for user-space applications which need 
> to remain backwards compatible to older versions of the kernel and of libc.
> 

afaik, execve() is the only reason for retaining __KERNEL_SYSCALLS__
support on x86.

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[dkegel]

On 3/9/06, Andrew Morton <akpm@osdl.org> wrote:
> I doubt if glibc is borrowing the kernel's macros.

I think it is, though.

When I build gcc/glibc toolchains, I have to use kernel headers.
I used to directly use the ones in the kernel.org tree, but
those aren't quite intended for use in userspace; fortunately,
Mariusz Mazur's sanitized kernel headers work great.

I'd like to see these patches go in to the sanitized kernel headers
and/or the kernel.org tree.  I imagine that putting them in the kernel.org
tree is right, and they'd naturally percolate from there to the
various sanitized headers projects.

See also http://lkml.org/lkml/2006/1/7/51
- Dan

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Daniel Jacobowitz]

On Thu, Mar 09, 2006 at 07:36:25PM -0800, dkegel wrote:
> On 3/9/06, Andrew Morton <akpm@osdl.org> wrote:
> > I doubt if glibc is borrowing the kernel's macros.
> 
> I think it is, though.
> 
> When I build gcc/glibc toolchains, I have to use kernel headers.
> I used to directly use the ones in the kernel.org tree, but
> those aren't quite intended for use in userspace; fortunately,
> Mariusz Mazur's sanitized kernel headers work great.
> 
> I'd like to see these patches go in to the sanitized kernel headers
> and/or the kernel.org tree.  I imagine that putting them in the kernel.org
> tree is right, and they'd naturally percolate from there to the
> various sanitized headers projects.

It uses the headers for many things.  It does not use the _syscallX
macros.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[dkegel]

On 3/10/06, Daniel Jacobowitz <dan@debian.org> wrote:
> > I'd like to see these patches go in to the sanitized kernel headers
> > and/or the kernel.org tree.  I imagine that putting them in the kernel.org
> > tree is right, and they'd naturally percolate from there to the
> > various sanitized headers projects.
>
> It uses the headers for many things.  It does not use the _syscallX
> macros.

Sorry, I misspoke.
The glibc build process makes the _syscallX macros available
to userspace via the <asm/syscalls.h> include.
So even if glibc doesn't use those macros directly,
it does seem to pass them along.  Which is how
Markus got on to this whole topic in the first place.

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386 (updated patch)

[Markus Gutschke]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

From: Markus Gutschke <markus@google.com>

Gcc reserves %ebx when compiling position-independent-code on i386. This 
means, the _syscallX() macros in include/asm-i386/unistd.h will not 
compile. This patch is against 2.6.15.6 and changes the existing macros 
to take special care to preserve %ebx.

The bug can be tracked at http://bugzilla.kernel.org/show_bug.cgi?id=6204

Signed-off-by: Markus Gutschke <markus@google.com>

---

Andrew Morton wrote:
> Markus Gutschke <markus@google.com> wrote:
>>That is certainly possible. The new macros work in both modes, but they 
>>are slightly less efficient than the old macros, if you have access to 
>>%ebx (i.e. in non-PIC code). If you prefer, we could just remove the old 
>>macros and unconditionally replace them with the new ones. 
> 
> I'd be OK with that - the kernel doesn't (shouldn't) care about the
> performance of __KERNEL_SYSCALLS__ stuff.  I doubt if glibc is borrowing
> the kernel's macros.

Would you like this patch better? It now unconditionally replaces the 
old macros with a fixed version. This will entail a minor performance 
penalty in non-PIC mode. But for the vast majority of applications the 
difference should be entire negligible.

Once this change has made it into the kernel, I will try to get it 
propagated into libc.


Markus

[-- Attachment #2: unistd.h.diff --]
[-- Type: text/x-patch, Size: 3226 bytes --]

--- linux-2.6.15.6/include/asm-i386/unistd.h.orig	2006-03-05 11:07:54.000000000 -0800
+++ linux-2.6.15.6/include/asm-i386/unistd.h	2006-03-10 14:33:10.000000000 -0800
@@ -330,9 +330,9 @@
 type name(type1 arg1) \
 { \
 long __res; \
-__asm__ volatile ("int $0x80" \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
 	: "=a" (__res) \
-	: "0" (__NR_##name),"b" ((long)(arg1)) : "memory"); \
+	: "0" (__NR_##name),"ri" ((long)(arg1)) : "memory"); \
 __syscall_return(type,__res); \
 }
 
@@ -340,9 +340,10 @@
 type name(type1 arg1,type2 arg2) \
 { \
 long __res; \
-__asm__ volatile ("int $0x80" \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
 	: "=a" (__res) \
-	: "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)) : "memory"); \
+	: "0" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)) \
+	: "memory"); \
 __syscall_return(type,__res); \
 }
 
@@ -350,9 +351,9 @@
 type name(type1 arg1,type2 arg2,type3 arg3) \
 { \
 long __res; \
-__asm__ volatile ("int $0x80" \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
 	: "=a" (__res) \
-	: "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \
+	: "0" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
 		  "d" ((long)(arg3)) : "memory"); \
 __syscall_return(type,__res); \
 }
@@ -361,9 +362,9 @@
 type name (type1 arg1, type2 arg2, type3 arg3, type4 arg4) \
 { \
 long __res; \
-__asm__ volatile ("int $0x80" \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; int $0x80 ; pop %%ebx" \
 	: "=a" (__res) \
-	: "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \
+	: "0" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
 	  "d" ((long)(arg3)),"S" ((long)(arg4)) : "memory"); \
 __syscall_return(type,__res); \
 } 
@@ -373,10 +374,12 @@
 type name (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5) \
 { \
 long __res; \
-__asm__ volatile ("int $0x80" \
+__asm__ volatile ("push %%ebx ; movl %2,%%ebx ; movl %1,%%eax ; " \
+                  "int $0x80 ; pop %%ebx" \
 	: "=a" (__res) \
-	: "0" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \
-	  "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5)) : "memory"); \
+	: "i" (__NR_##name),"ri" ((long)(arg1)),"c" ((long)(arg2)), \
+	  "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5)) \
+	: "memory"); \
 __syscall_return(type,__res); \
 }
 
@@ -385,11 +388,14 @@
 type name (type1 arg1,type2 arg2,type3 arg3,type4 arg4,type5 arg5,type6 arg6) \
 { \
 long __res; \
-__asm__ volatile ("push %%ebp ; movl %%eax,%%ebp ; movl %1,%%eax ; int $0x80 ; pop %%ebp" \
-	: "=a" (__res) \
-	: "i" (__NR_##name),"b" ((long)(arg1)),"c" ((long)(arg2)), \
-	  "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5)), \
-	  "0" ((long)(arg6)) : "memory"); \
+  struct { long __a1; long __a6; } __s = { (long)arg1, (long)arg6 }; \
+__asm__ volatile ("push %%ebp ; push %%ebx ; movl 4(%2),%%ebp ; " \
+                  "movl 0(%2),%%ebx ; movl %1,%%eax ; int $0x80 ; " \
+                  "pop %%ebx ;  pop %%ebp" \
+	: "=a" (__res) \
+	: "i" (__NR_##name),"0" ((long)(&__s)),"c" ((long)(arg2)), \
+	  "d" ((long)(arg3)),"S" ((long)(arg4)),"D" ((long)(arg5)) \
+	: "memory"); \
 __syscall_return(type,__res); \
 }
 

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386 (updated patch)

[dkegel]

On 3/10/06, Markus Gutschke <markus@google.com> wrote:
> Once this change has made it into the kernel, I will try to get it
> propagated into libc.

Cool...

I could be wrong, but I think "propagating into libc" here means
"propagating into
the sanitized kernel headers, e.g. the set at
http://ep09.pld-linux.org/~mmazur/linux-libc-headers/

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Arnd Bergmann]

Am Friday 10 March 2006 04:22 schrieb Andrew Morton:
> afaik, execve() is the only reason for retaining __KERNEL_SYSCALLS__
> support on x86.

Yes. Actually sh64 seems to be the only architecture left where
__KERNEL_SYSCALLS__ is used for something besides execve.

	Arnd <><

Re: [PATCH 1/1] x86: Make _syscallX() macros compile in PIC mode on i386

[Jan Engelhardt]

>> Gcc reserves %ebx when compiling position-independent-code on i386. This 
>>  means, the _syscallX() macros in include/asm-i386/unistd.h will not 
>>  compile. This patch is against 2.6.15.6 and adds a new set of macros 
>>  which will be used in PIC mode. These macros take special care to 
>>  preserve %ebx.
>
>But we don't compile the kernel with -fpic...  We might want to, for kdump
>convenience at some stage, perhaps.
>
UML. Maybe it does not build with -fpic/-fPIC either, but it's one case 
where it's more likely than with a "true" kernel.


Jan Engelhardt
--