From: Markus Gutschke <[email protected]>
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 <[email protected]>
---
Markus Gutschke <[email protected]> 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.
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
Markus Gutschke <[email protected]> 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.
On 3/9/06, Andrew Morton <[email protected]> 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
>> 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
--
From: Markus Gutschke <[email protected]>
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 <[email protected]>
---
Andrew Morton wrote:
> Markus Gutschke <[email protected]> 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
On 3/10/06, Markus Gutschke <[email protected]> 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/
On Thu, Mar 09, 2006 at 07:36:25PM -0800, dkegel wrote:
> On 3/9/06, Andrew Morton <[email protected]> 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
On 3/10/06, Daniel Jacobowitz <[email protected]> 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.
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 <><