leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
b6e4bc125f
linux/arch/arm64/include/asm/linkage.h

24 lines
518 B
C
Raw Normal View History

arm64: fix alignment padding in assembly code An interesting effect of using the generic version of linkage.h is that the padding is defined in terms of x86 NOPs, which can have even more interesting effects when the assembly code looks like this: ENTRY(func1) mov x0, xzr ENDPROC(func1) // fall through ENTRY(func2) mov x0, #1 ret ENDPROC(func2) Admittedly, the code is not very nice. But having code from another architecture doesn't look completely sane either. The fix is to add arm64's version of linkage.h, which causes the insertion of proper AArch64 NOPs. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2012-10-19 16:33:27 +00:00
#ifndef __ASM_LINKAGE_H
#define __ASM_LINKAGE_H
arm64: relax assembly code alignment from 16 byte to 4 byte Aarch64 instructions must be word aligned. The current 16 byte alignment is more than enough. Relax it into 4 byte alignment. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2017-09-18 10:20:19 +00:00
#define __ALIGN .align 2
#define __ALIGN_STR ".align 2"
arm64: fix alignment padding in assembly code An interesting effect of using the generic version of linkage.h is that the padding is defined in terms of x86 NOPs, which can have even more interesting effects when the assembly code looks like this: ENTRY(func1) mov x0, xzr ENDPROC(func1) // fall through ENTRY(func2) mov x0, #1 ret ENDPROC(func2) Admittedly, the code is not very nice. But having code from another architecture doesn't look completely sane either. The fix is to add arm64's version of linkage.h, which causes the insertion of proper AArch64 NOPs. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2012-10-19 16:33:27 +00:00
arm64: asm: Add new-style position independent function annotations As part of an effort to make the annotations in assembly code clearer and more consistent new macros have been introduced, including replacements for ENTRY() and ENDPROC(). On arm64 we have ENDPIPROC(), a custom version of ENDPROC() which is used for code that will need to run in position independent environments like EFI, it creates an alias for the function with the prefix __pi_ and then emits the standard ENDPROC. Add new-style macros to replace this which expand to the standard SYM_FUNC_*() and SYM_FUNC_ALIAS_*(), resulting in the same object code. These are added in linkage.h for consistency with where the generic assembler code has its macros. Signed-off-by: Mark Brown <broonie@kernel.org> [will: Rename 'WEAK' macro, use ';' instead of ASM_NL, deprecate ENDPIPROC] Signed-off-by: Will Deacon <will@kernel.org>
2020-01-06 19:58:16 +00:00
/*
* Annotate a function as position independent, i.e., safe to be called before
* the kernel virtual mapping is activated.
*/
#define SYM_FUNC_START_PI(x) \
SYM_FUNC_START_ALIAS(__pi_##x); \
SYM_FUNC_START(x)
#define SYM_FUNC_START_WEAK_PI(x) \
SYM_FUNC_START_ALIAS(__pi_##x); \
SYM_FUNC_START_WEAK(x)
#define SYM_FUNC_END_PI(x) \
SYM_FUNC_END(x); \
SYM_FUNC_END_ALIAS(__pi_##x)
arm64: fix alignment padding in assembly code An interesting effect of using the generic version of linkage.h is that the padding is defined in terms of x86 NOPs, which can have even more interesting effects when the assembly code looks like this: ENTRY(func1) mov x0, xzr ENDPROC(func1) // fall through ENTRY(func2) mov x0, #1 ret ENDPROC(func2) Admittedly, the code is not very nice. But having code from another architecture doesn't look completely sane either. The fix is to add arm64's version of linkage.h, which causes the insertion of proper AArch64 NOPs. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2012-10-19 16:33:27 +00:00
#endif
Reference in New Issue Copy Permalink