x86: Unify include/asm-x86/linkage_[32|64].h

RFC PATCH In review Harvey Harrison 5 participants 13 messages Dec 4, 2007 – Dec 5, 2007

lore

Share & tools

lore

Harvey Harrison

author

2007-12-04 20:54 UTC #0 lore raw

RFC PATCH 1/1 x86: Unify include/asm-x86/linkage_[32|64].h

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(-)

include/asm-x86/linkage.h +18 -3

index 94b257f..5a4c959 100644
@@ -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
+

include/asm-x86/linkage_32.h deleted +0 ~~-15~~

deleted file mode 100644
index f4a6eba..0000000
@@ -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

include/asm-x86/linkage_64.h deleted +0 -6

deleted file mode 100644
index b5f39d0..0000000
@@ -1,6 +0,0 @@
-#ifndef __ASM_LINKAGE_H
-#define __ASM_LINKAGE_H
-
-#define __ALIGN .p2align 4,,15
-
-#endif

Signature · 1 line

1.5.3.7.2094.gff6c

Ingo Molnar

2007-12-04 21:33 UTC #1 lore raw

Quoted 3 lines · Harvey Harrison

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

Harvey Harrison

author

2007-12-04 22:21 UTC #2 lore raw

Quoted 11 lines · Ingo Molnar

Quoted 3 lines · Harvey Harrison
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

Ingo Molnar

2007-12-04 22:27 UTC #3 lore raw

Quoted 13 lines · Harvey Harrison

Quoted 11 lines · Ingo Molnar
Quoted 3 lines · Harvey Harrison
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.)

Quoted 4 lines

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

Harvey Harrison

author

2007-12-04 22:33 UTC #4 lore raw

Quoted 10 lines · Ingo Molnar

Quoted 4 lines · Harvey Harrison
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.

Quoted 5 lines

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

Adrian Bunk

2007-12-04 22:45 UTC #5 lore raw

In reply to Ingo Molnar

Quoted 21 lines · Ingo Molnar

Quoted 13 lines · Harvey Harrison
Quoted 11 lines · Ingo Molnar
Quoted 3 lines · Harvey Harrison
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.)
Quoted 4 lines
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?

Quoted 4 lines

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.

Quoted 1 line

Ingo

cu
Adrian

Signature · 4 lines

       "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

Harvey Harrison

author

2007-12-04 23:04 UTC #6 lore raw

Quoted 22 lines · Adrian Bunk

Quoted 21 lines · Ingo Molnar
Quoted 17 lines · Harvey Harrison
Quoted 11 lines · Ingo Molnar
Quoted 3 lines · Harvey Harrison
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?

Quoted 6 lines

Quoted 4 lines
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

Adrian Bunk

2007-12-04 23:15 UTC #7 lore raw

Quoted 24 lines · Harvey Harrison

Quoted 22 lines · Adrian Bunk
Quoted 21 lines · Ingo Molnar
Quoted 17 lines · Harvey Harrison
Quoted 11 lines · Ingo Molnar
Quoted 3 lines · Harvey Harrison
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?

Quoted 8 lines

Quoted 6 lines
Quoted 4 lines
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.

Quoted 1 line

Harvey

cu
Adrian

Signature · 4 lines

       "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

Jeff Dike

2007-12-05 00:20 UTC #8 lore raw

Quoted 3 lines · Adrian Bunk

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

Signature · 1 line

Work email - jdike at linux dot intel dot com

Adrian Bunk

2007-12-05 09:31 UTC #9 lore raw

Quoted 8 lines · Jeff Dike

Quoted 3 lines · Adrian Bunk
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.

Quoted 1 line

Jeff

cu
Adrian

Signature · 4 lines

       "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

Ingo Molnar

2007-12-05 10:19 UTC #10 lore raw

Quoted 6 lines · Adrian Bunk

Quoted 5 lines · Jeff Dike
Quoted 3 lines · Adrian Bunk
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.

Quoted 6 lines

Quoted 3 lines
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

Adrian Bunk

2007-12-05 12:17 UTC #11 lore raw

Quoted 9 lines · Ingo Molnar

Quoted 6 lines · Adrian Bunk
Quoted 5 lines · Jeff Dike
Quoted 3 lines · Adrian Bunk
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.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
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...

Quoted 1 line

Ingo

cu
Adrian

Signature · 4 lines

       "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

Jeff Dike

2007-12-05 00:18 UTC #12 lore raw

In reply to Adrian Bunk

Quoted 6 lines · Adrian Bunk

Quoted 4 lines
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

Signature · 1 line

Work email - jdike at linux dot intel dot com