UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/arch/x86/include/asm/linkage.h

62 lines
2.0 KiB
C
Raw Normal View History

x86: Fix ASM_X86__ header guards Change header guards named "ASM_X86__*" to "_ASM_X86_*" since: a. the double underscore is ugly and pointless. b. no leading underscore violates namespace constraints. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-23 13:26:29 +08:00
#ifndef _ASM_X86_LINKAGE_H
#define _ASM_X86_LINKAGE_H
x86: unify include/asm-x86/linkage_[32|64].h 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 <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:31:07 +08:00
x86: shrink __ALIGN and __ALIGN_STR definitions Impact: cleanup 1) .p2align 4 and .align 16 are the same meaning (until a.out format for i386 is used which is not our case for CONFIG_X86_ALIGNMENT_16 anyway) 2) having 15 as max allowed bytes to be skipped does not make sense on modulo 16 Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> LKML-Reference: <20090309171951.GE9945@localhost> [ small cleanup, use __stringify(), etc. ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-10 01:19:51 +08:00
#include <linux/stringify.h>
x86, tracing: add notrace to asm-x86/linkage.h notrace signals that a function should not be traced. Most of the time this is used by tracers to annotate code that cannot be traced - it's in a volatile state (such as in user vdso context or NMI context) or it's in the tracer internals. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-04-17 23:40:51 +08:00
#undef notrace
#define notrace __attribute__((no_instrument_function))
i386/x86_64: move headers to include/asm-x86 Move the headers to include/asm-x86 and fixup the header install make rules Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-10-11 17:20:03 +08:00
#ifdef CONFIG_X86_32
x86: unify include/asm-x86/linkage_[32|64].h 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 <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:31:07 +08:00
#define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0)))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
Add commentary about the new "asmlinkage_protect()" macro It's really a pretty ugly thing to need, and some day it will hopefully be obviated by teaching gcc about the magic calling conventions for the low-level system call code, but in the meantime we can at least add big honking comments about why we need these insane and strange macros. I took my comments from my version of the macro, but I ended up deciding to just pick Roland's version of the actual code instead (with his prettier syntax that uses vararg macros). Thus the previous two commits that actually implement it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 08:35:23 +08:00
/*
* Make sure the compiler doesn't do anything stupid with the
* arguments on the stack - they are owned by the *caller*, not
* the callee. This just fools gcc into not spilling into them,
* and keeps it from doing tailcall recursion and/or using the
* stack slots for temporaries, since they are live and "used"
* all the way to the end of the function.
*
* NOTE! On x86-64, all the arguments are in registers, so this
* only matters on a 32-bit kernel.
*/
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
#define asmlinkage_protect(n, ret, args...) \
__asmlinkage_protect##n(ret, ##args)
#define __asmlinkage_protect_n(ret, args...) \
__asm__ __volatile__ ("" : "=r" (ret) : "0" (ret), ##args)
#define __asmlinkage_protect0(ret) \
__asmlinkage_protect_n(ret)
#define __asmlinkage_protect1(ret, arg1) \
ix86: Tighten asmlinkage_protect() constraints While the description of the commit that originally introduced asmlinkage_protect() validly says that this doesn't guarantee clobbering of the function arguments, using "m" constraints rather than "g" ones reduces the risk (by making it less attractive to the compiler to move those variables into registers) and generally results in better code (because we know the arguments are in memory anyway, and are frequently - if not always - used just once, with the second [compiler visible] use in asmlinkage_protect() itself being a fake one). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <roland@hack.frob.com> Cc: <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/50FE84EC02000078000B83B7@nat28.tlf.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-01-22 19:24:12 +08:00
__asmlinkage_protect_n(ret, "m" (arg1))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
#define __asmlinkage_protect2(ret, arg1, arg2) \
ix86: Tighten asmlinkage_protect() constraints While the description of the commit that originally introduced asmlinkage_protect() validly says that this doesn't guarantee clobbering of the function arguments, using "m" constraints rather than "g" ones reduces the risk (by making it less attractive to the compiler to move those variables into registers) and generally results in better code (because we know the arguments are in memory anyway, and are frequently - if not always - used just once, with the second [compiler visible] use in asmlinkage_protect() itself being a fake one). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <roland@hack.frob.com> Cc: <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/50FE84EC02000078000B83B7@nat28.tlf.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-01-22 19:24:12 +08:00
__asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
#define __asmlinkage_protect3(ret, arg1, arg2, arg3) \
ix86: Tighten asmlinkage_protect() constraints While the description of the commit that originally introduced asmlinkage_protect() validly says that this doesn't guarantee clobbering of the function arguments, using "m" constraints rather than "g" ones reduces the risk (by making it less attractive to the compiler to move those variables into registers) and generally results in better code (because we know the arguments are in memory anyway, and are frequently - if not always - used just once, with the second [compiler visible] use in asmlinkage_protect() itself being a fake one). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <roland@hack.frob.com> Cc: <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/50FE84EC02000078000B83B7@nat28.tlf.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-01-22 19:24:12 +08:00
__asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
#define __asmlinkage_protect4(ret, arg1, arg2, arg3, arg4) \
ix86: Tighten asmlinkage_protect() constraints While the description of the commit that originally introduced asmlinkage_protect() validly says that this doesn't guarantee clobbering of the function arguments, using "m" constraints rather than "g" ones reduces the risk (by making it less attractive to the compiler to move those variables into registers) and generally results in better code (because we know the arguments are in memory anyway, and are frequently - if not always - used just once, with the second [compiler visible] use in asmlinkage_protect() itself being a fake one). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <roland@hack.frob.com> Cc: <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/50FE84EC02000078000B83B7@nat28.tlf.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-01-22 19:24:12 +08:00
__asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3), \
"m" (arg4))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
#define __asmlinkage_protect5(ret, arg1, arg2, arg3, arg4, arg5) \
ix86: Tighten asmlinkage_protect() constraints While the description of the commit that originally introduced asmlinkage_protect() validly says that this doesn't guarantee clobbering of the function arguments, using "m" constraints rather than "g" ones reduces the risk (by making it less attractive to the compiler to move those variables into registers) and generally results in better code (because we know the arguments are in memory anyway, and are frequently - if not always - used just once, with the second [compiler visible] use in asmlinkage_protect() itself being a fake one). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <roland@hack.frob.com> Cc: <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/50FE84EC02000078000B83B7@nat28.tlf.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-01-22 19:24:12 +08:00
__asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3), \
"m" (arg4), "m" (arg5))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
#define __asmlinkage_protect6(ret, arg1, arg2, arg3, arg4, arg5, arg6) \
ix86: Tighten asmlinkage_protect() constraints While the description of the commit that originally introduced asmlinkage_protect() validly says that this doesn't guarantee clobbering of the function arguments, using "m" constraints rather than "g" ones reduces the risk (by making it less attractive to the compiler to move those variables into registers) and generally results in better code (because we know the arguments are in memory anyway, and are frequently - if not always - used just once, with the second [compiler visible] use in asmlinkage_protect() itself being a fake one). Signed-off-by: Jan Beulich <jbeulich@suse.com> Cc: <roland@hack.frob.com> Cc: <viro@zeniv.linux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/50FE84EC02000078000B83B7@nat28.tlf.novell.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-01-22 19:24:12 +08:00
__asmlinkage_protect_n(ret, "m" (arg1), "m" (arg2), "m" (arg3), \
"m" (arg4), "m" (arg5), "m" (arg6))
asmlinkage_protect replaces prevent_tail_call The prevent_tail_call() macro works around the problem of the compiler clobbering argument words on the stack, which for asmlinkage functions is the caller's (user's) struct pt_regs. The tail/sibling-call optimization is not the only way that the compiler can decide to use stack argument words as scratch space, which we have to prevent. Other optimizations can do it too. Until we have new compiler support to make "asmlinkage" binding on the compiler's own use of the stack argument frame, we have work around all the manifestations of this issue that crop up. More cases seem to be prevented by also keeping the incoming argument variables live at the end of the function. This makes their original stack slots attractive places to leave those variables, so the compiler tends not clobber them for something else. It's still no guarantee, but it handles some observed cases that prevent_tail_call() did not. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-04-11 06:37:38 +08:00
x86: linkage.h - guard assembler specifics by __ASSEMBLY__ Stephen Rothwell reported: |Today's linux-next build (x86_64 allmodconfig) produced this warning: | |In file included from drivers/char/epca.c:49: |drivers/char/digiFep1.h:7:1: warning: "GLOBAL" redefined |In file included from include/linux/linkage.h:5, | from include/linux/kernel.h:11, | from arch/x86/include/asm/system.h:10, | from arch/x86/include/asm/processor.h:17, | from include/linux/prefetch.h:14, | from include/linux/list.h:6, | from include/linux/module.h:9, | from drivers/char/epca.c:29: |arch/x86/include/asm/linkage.h:55:1: warning: this is the location of the previous definition | |Probably introduced by commit 95695547a7db44b88a7ee36cf5df188de267e99e |("x86: asm linkage - introduce GLOBAL macro") from the x86 tree. Any assembler specific snippets being placed in headers are to be protected by __ASSEMBLY__. Fixed. Also move __ALIGN definition under the same protection as well. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> LKML-Reference: <20090306160833.GB7420@localhost> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-07 00:08:34 +08:00
#endif /* CONFIG_X86_32 */
#ifdef __ASSEMBLY__
x86: unify include/asm-x86/linkage_[32|64].h 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 <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:31:07 +08:00
x86: asm linkage - introduce GLOBAL macro If the code is time critical and this entry is called from other places we use ENTRY to have it globally defined and especially aligned. Contrary we have some snippets which are size critical. So we use plane ".globl name; name:" directive. Introduce GLOBAL macro for this. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-02-14 05:50:18 +08:00
#define GLOBAL(name) \
.globl name; \
name:
x86: shrink __ALIGN and __ALIGN_STR definitions Impact: cleanup 1) .p2align 4 and .align 16 are the same meaning (until a.out format for i386 is used which is not our case for CONFIG_X86_ALIGNMENT_16 anyway) 2) having 15 as max allowed bytes to be skipped does not make sense on modulo 16 Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> LKML-Reference: <20090309171951.GE9945@localhost> [ small cleanup, use __stringify(), etc. ] Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-10 01:19:51 +08:00
#if defined(CONFIG_X86_64) || defined(CONFIG_X86_ALIGNMENT_16)
#define __ALIGN .p2align 4, 0x90
#define __ALIGN_STR __stringify(__ALIGN)
x86: unify include/asm-x86/linkage_[32|64].h 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 <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:31:07 +08:00
#endif
x86: linkage.h - guard assembler specifics by __ASSEMBLY__ Stephen Rothwell reported: |Today's linux-next build (x86_64 allmodconfig) produced this warning: | |In file included from drivers/char/epca.c:49: |drivers/char/digiFep1.h:7:1: warning: "GLOBAL" redefined |In file included from include/linux/linkage.h:5, | from include/linux/kernel.h:11, | from arch/x86/include/asm/system.h:10, | from arch/x86/include/asm/processor.h:17, | from include/linux/prefetch.h:14, | from include/linux/list.h:6, | from include/linux/module.h:9, | from drivers/char/epca.c:29: |arch/x86/include/asm/linkage.h:55:1: warning: this is the location of the previous definition | |Probably introduced by commit 95695547a7db44b88a7ee36cf5df188de267e99e |("x86: asm linkage - introduce GLOBAL macro") from the x86 tree. Any assembler specific snippets being placed in headers are to be protected by __ASSEMBLY__. Fixed. Also move __ALIGN definition under the same protection as well. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> LKML-Reference: <20090306160833.GB7420@localhost> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-03-07 00:08:34 +08:00
#endif /* __ASSEMBLY__ */
x86: Fix ASM_X86__ header guards Change header guards named "ASM_X86__*" to "_ASM_X86_*" since: a. the double underscore is ugly and pointless. b. no leading underscore violates namespace constraints. Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2008-10-23 13:26:29 +08:00
#endif /* _ASM_X86_LINKAGE_H */
x86: unify include/asm-x86/linkage_[32|64].h 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 <harvey.harrison@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 20:31:07 +08:00