Adding LKML to CC
Remove definitions of FASTCALL/fastcall from linkage_32 as compiled with
-regparm=3 by default since 2.6.20 and should no longer be needed.
CONFIG X86_64 and CONFIG_X86_ALIGNMENT_16 are mutually exclusive as found
in Kconfig.cpu so it should be fine to test them separately.
Signed-off-by: Harvey Harrison <[email protected]>
---
I'm not sure if the definition of asmlinkage and prevent_tail_call can be
omitted as well and let the linux/linkage.h version get picked up instead.
Smarter people than I will have to figure that out.
include/asm-x86/linkage.h | 21 ++++++++++++++++++---
include/asm-x86/linkage_32.h | 15 ---------------
include/asm-x86/linkage_64.h | 6 ------
3 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/include/asm-x86/linkage.h b/include/asm-x86/linkage.h
index 94b257f..5a4c959 100644
--- a/include/asm-x86/linkage.h
+++ b/include/asm-x86/linkage.h
@@ -1,5 +1,20 @@
+#ifndef __ASM_LINKAGE_H
+#define __ASM_LINKAGE_H
+
+#ifdef CONFIG_X86_64
+#define __ALIGN .p2align 4,,15
+#define __ALIGN_STR ".p2align 4,,15"
+#endif
+
#ifdef CONFIG_X86_32
-# include "linkage_32.h"
-#else
-# include "linkage_64.h"
+#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
+#define prevent_tail_call(ret) __asm__ ("" : "=r" (ret) : "0" (ret))
+#endif
+
+#ifdef CONFIG_X86_ALIGNMENT_16
+#define __ALIGN .align 16,0x90
+#define __ALIGN_STR ".align 16,0x90"
+#endif
+
#endif
+
diff --git a/include/asm-x86/linkage_32.h b/include/asm-x86/linkage_32.h
deleted file mode 100644
index f4a6eba..0000000
--- a/include/asm-x86/linkage_32.h
+++ /dev/null
@@ -1,15 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
-#define FASTCALL(x) x __attribute__((regparm(3)))
-#define fastcall __attribute__((regparm(3)))
-
-#define prevent_tail_call(ret) __asm__ ("" : "=r" (ret) : "0" (ret))
-
-#ifdef CONFIG_X86_ALIGNMENT_16
-#define __ALIGN .align 16,0x90
-#define __ALIGN_STR ".align 16,0x90"
-#endif
-
-#endif
diff --git a/include/asm-x86/linkage_64.h b/include/asm-x86/linkage_64.h
deleted file mode 100644
index b5f39d0..0000000
--- a/include/asm-x86/linkage_64.h
+++ /dev/null
@@ -1,6 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-#define __ALIGN .p2align 4,,15
-
-#endif
--
1.5.3.7.2094.gff6c
* Harvey Harrison <[email protected]> wrote:
> I'm not sure if the definition of asmlinkage and prevent_tail_call can
> be omitted as well and let the linux/linkage.h version get picked up
> instead.
no, we cannot remove them - asmlinkage is needed for the syscall entry
(and other entry code) to work, the and the prevent_tail_call works
around a compiler bug. (which might or might not be fixed in latest gcc
- but we generally dont remove workarounds unless we are really sure
it's fine.)
so your patch looks good to me, i've queued it up.
Ingo
On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> * Harvey Harrison <[email protected]> wrote:
>
> > I'm not sure if the definition of asmlinkage and prevent_tail_call can
> > be omitted as well and let the linux/linkage.h version get picked up
> > instead.
>
> no, we cannot remove them - asmlinkage is needed for the syscall entry
> (and other entry code) to work, the and the prevent_tail_call works
> around a compiler bug. (which might or might not be fixed in latest gcc
> - but we generally dont remove workarounds unless we are really sure
> it's fine.)
OK, but if this patch is acceptable, then there is no more places in the
tree that define the FASTCALL macro, other than the empty default in
include/linux/linkage.h. So I think a second step would be to start to
get rid of FASTCALL callers elsewhere in the tree...thoughts?
Cheers,
Harvey
* Harvey Harrison <[email protected]> wrote:
> On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> > * Harvey Harrison <[email protected]> wrote:
> >
> > > I'm not sure if the definition of asmlinkage and prevent_tail_call can
> > > be omitted as well and let the linux/linkage.h version get picked up
> > > instead.
> >
> > no, we cannot remove them - asmlinkage is needed for the syscall
> > entry (and other entry code) to work, the and the prevent_tail_call
> > works around a compiler bug. (which might or might not be fixed in
> > latest gcc - but we generally dont remove workarounds unless we are
> > really sure it's fine.)
>
> OK, but if this patch is acceptable, then there is no more places in
> the tree that define the FASTCALL macro, other than the empty default
> in include/linux/linkage.h. So I think a second step would be to
> start to get rid of FASTCALL callers elsewhere in the tree...thoughts?
the removal of FASTCALL is fine: the default (and only) compiler model
for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
the empty one in linux/linkage.h.
btw., removal of FASTCALL from the tree is worthwile after this: it
should probably be done via the -mm tree, because it's more of a generic
kernel matter than an arch/x86 matter.
Ingo
On Tue, 2007-12-04 at 23:27 +0100, Ingo Molnar wrote:
> * Harvey Harrison <[email protected]> wrote:
> > OK, but if this patch is acceptable, then there is no more places in
> > the tree that define the FASTCALL macro, other than the empty default
> > in include/linux/linkage.h. So I think a second step would be to
> > start to get rid of FASTCALL callers elsewhere in the tree...thoughts?
>
> the removal of FASTCALL is fine: the default (and only) compiler model
> for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
> the empty one in linux/linkage.h.
>
> btw., removal of FASTCALL from the tree is worthwile after this: it
> should probably be done via the -mm tree, because it's more of a generic
> kernel matter than an arch/x86 matter.
>
> Ingo
Agreed, just noting that there was nobody defining it anymore, it's
widespread enough that I'll submit them separately to appropriate
maintainers and they can dribble in over time.
Cheers,
Harvey
On Tue, Dec 04, 2007 at 11:27:17PM +0100, Ingo Molnar wrote:
>
> * Harvey Harrison <[email protected]> wrote:
>
> > On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> > > * Harvey Harrison <[email protected]> wrote:
> > >
> > > > I'm not sure if the definition of asmlinkage and prevent_tail_call can
> > > > be omitted as well and let the linux/linkage.h version get picked up
> > > > instead.
> > >
> > > no, we cannot remove them - asmlinkage is needed for the syscall
> > > entry (and other entry code) to work, the and the prevent_tail_call
> > > works around a compiler bug. (which might or might not be fixed in
> > > latest gcc - but we generally dont remove workarounds unless we are
> > > really sure it's fine.)
> >
> > OK, but if this patch is acceptable, then there is no more places in
> > the tree that define the FASTCALL macro, other than the empty default
> > in include/linux/linkage.h. So I think a second step would be to
> > start to get rid of FASTCALL callers elsewhere in the tree...thoughts?
>
> the removal of FASTCALL is fine: the default (and only) compiler model
> for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
> the empty one in linux/linkage.h.
>...
But please ensure that they stay in assembler code also used by UML.
> Ingo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, 2007-12-04 at 23:45 +0100, Adrian Bunk wrote:
> On Tue, Dec 04, 2007 at 11:27:17PM +0100, Ingo Molnar wrote:
> >
> > * Harvey Harrison <[email protected]> wrote:
> >
> > > On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> > > > * Harvey Harrison <[email protected]> wrote:
> > > >
> > > > > I'm not sure if the definition of asmlinkage and prevent_tail_call can
> > > > > be omitted as well and let the linux/linkage.h version get picked up
> > > > > instead.
> > > >
> > > > no, we cannot remove them - asmlinkage is needed for the syscall
> > > > entry (and other entry code) to work, the and the prevent_tail_call
> > > > works around a compiler bug. (which might or might not be fixed in
> > > > latest gcc - but we generally dont remove workarounds unless we are
> > > > really sure it's fine.)
> > >
> > > OK, but if this patch is acceptable, then there is no more places in
> > > the tree that define the FASTCALL macro, other than the empty default
> > > in include/linux/linkage.h. So I think a second step would be to
> > > start to get rid of FASTCALL callers elsewhere in the tree...thoughts?
> >
> > the removal of FASTCALL is fine: the default (and only) compiler model
> > for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
> > the empty one in linux/linkage.h.
> >...
>
> But please ensure that they stay in assembler code also used by UML.
I'm curious how UML is using FASTCALL/fastcall. Any pointers?
Harvey
On Tue, Dec 04, 2007 at 02:57:55PM -0800, Harvey Harrison wrote:
>
> On Tue, 2007-12-04 at 23:45 +0100, Adrian Bunk wrote:
> > On Tue, Dec 04, 2007 at 11:27:17PM +0100, Ingo Molnar wrote:
> > >
> > > * Harvey Harrison <[email protected]> wrote:
> > >
> > > > On Tue, 2007-12-04 at 22:32 +0100, Ingo Molnar wrote:
> > > > > * Harvey Harrison <[email protected]> wrote:
> > > > >
> > > > > > I'm not sure if the definition of asmlinkage and prevent_tail_call can
> > > > > > be omitted as well and let the linux/linkage.h version get picked up
> > > > > > instead.
> > > > >
> > > > > no, we cannot remove them - asmlinkage is needed for the syscall
> > > > > entry (and other entry code) to work, the and the prevent_tail_call
> > > > > works around a compiler bug. (which might or might not be fixed in
> > > > > latest gcc - but we generally dont remove workarounds unless we are
> > > > > really sure it's fine.)
> > > >
> > > > OK, but if this patch is acceptable, then there is no more places in
> > > > the tree that define the FASTCALL macro, other than the empty default
> > > > in include/linux/linkage.h. So I think a second step would be to
> > > > start to get rid of FASTCALL callers elsewhere in the tree...thoughts?
> > >
> > > the removal of FASTCALL is fine: the default (and only) compiler model
> > > for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
> > > the empty one in linux/linkage.h.
> > >...
> >
> > But please ensure that they stay in assembler code also used by UML.
>
> I'm curious how UML is using FASTCALL/fastcall. Any pointers?
UML can't switch to the regparm(3) convention on i386 since it links
with userspace code, so if assembler code uses this calling convention
we need the C prototype of it annotated accordingly.
> Harvey
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Dec 04, 2007 at 11:45:43PM +0100, Adrian Bunk wrote:
> > the removal of FASTCALL is fine: the default (and only) compiler model
> > for x86 (32-bit) is regparm(3), so the regparm(3) macro is equivalent to
> > the empty one in linux/linkage.h.
> >...
>
> But please ensure that they stay in assembler code also used by UML.
Why? AFAIK, whatever works for x86 will also be fine for UML.
Jeff
--
Work email - jdike at linux dot intel dot com
On Wed, Dec 05, 2007 at 12:15:19AM +0100, Adrian Bunk wrote:
> UML can't switch to the regparm(3) convention on i386 since it links
> with userspace code, so if assembler code uses this calling convention
> we need the C prototype of it annotated accordingly.
We're not talking about a global calling convention switch, right?
We're talking about selected functions only, in which case, the fact
that UML links against libc is irrelevant.
Jeff
--
Work email - jdike at linux dot intel dot com
On Tue, Dec 04, 2007 at 07:19:45PM -0500, Jeff Dike wrote:
> On Wed, Dec 05, 2007 at 12:15:19AM +0100, Adrian Bunk wrote:
> > UML can't switch to the regparm(3) convention on i386 since it links
> > with userspace code, so if assembler code uses this calling convention
> > we need the C prototype of it annotated accordingly.
>
> We're not talking about a global calling convention switch, right?
> We're talking about selected functions only, in which case, the fact
> that UML links against libc is irrelevant.
The non-UML i386 switched to globally using the regparm(3) calling
convention in 2.6.20.
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
* Adrian Bunk <[email protected]> wrote:
> On Tue, Dec 04, 2007 at 07:19:45PM -0500, Jeff Dike wrote:
> > On Wed, Dec 05, 2007 at 12:15:19AM +0100, Adrian Bunk wrote:
> > > UML can't switch to the regparm(3) convention on i386 since it links
> > > with userspace code, so if assembler code uses this calling convention
> > > we need the C prototype of it annotated accordingly.
> >
> > We're not talking about a global calling convention switch, right?
> > We're talking about selected functions only, in which case, the fact
> > that UML links against libc is irrelevant.
>
> The non-UML i386 switched to globally using the regparm(3) calling
> convention in 2.6.20.
maybe i'm a bit dense, but why cannot UML switch to -mregparm=3 too?
Ingo
On Wed, Dec 05, 2007 at 11:18:45AM +0100, Ingo Molnar wrote:
>
> * Adrian Bunk <[email protected]> wrote:
>
> > On Tue, Dec 04, 2007 at 07:19:45PM -0500, Jeff Dike wrote:
> > > On Wed, Dec 05, 2007 at 12:15:19AM +0100, Adrian Bunk wrote:
> > > > UML can't switch to the regparm(3) convention on i386 since it links
> > > > with userspace code, so if assembler code uses this calling convention
> > > > we need the C prototype of it annotated accordingly.
> > >
> > > We're not talking about a global calling convention switch, right?
> > > We're talking about selected functions only, in which case, the fact
> > > that UML links against libc is irrelevant.
> >
> > The non-UML i386 switched to globally using the regparm(3) calling
> > convention in 2.6.20.
>
> maybe i'm a bit dense, but why cannot UML switch to -mregparm=3 too?
The UML kernel is linked against libc...
> Ingo
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed