maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/arm-thumb-interwork-ifunc.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

64 lines
1.7 KiB
ArmAsm
Raw Normal View History

[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
// REQUIRES: arm
// RUN: llvm-mc --triple=armv7a-linux-gnueabihf -arm-add-build-attributes -filetype=obj -o %t.o %s
// RUN: ld.lld %t.o -o %t
[ELF][test] Fix some llvm-objdump RUN lines which don't actually test anything
2020-08-20 13:48:28 +08:00
// RUN: llvm-objdump --triple=armv7a-none-linux-gnueabi -d --no-show-raw-insn %t | FileCheck %s
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
[ELF] Keep st_type for symbol assignment PR46970: for `alias = aliasee`, the alias can be used in relocation processing and on ARM st_type does affect Thumb interworking. It is thus desirable for the alias to get the same st_type. Note that the st_size field should not be inherited because some tools use st_size=0 as a heuristic to detect aliases. Retaining st_size can thwart such heuristics and cause aliases to be preferred over the original symbols. Differential Revision: https://reviews.llvm.org/D86263
2020-08-21 07:05:27 +08:00
/// A symbol assignment defined alias inherits st_type and gets the same treatment.
// RUN: llvm-mc --triple=armv7a-linux-gnueabihf -arm-add-build-attributes -filetype=obj --defsym ALIAS=1 -o %t1.o %s
// RUN: ld.lld --defsym foo=foo1 %t1.o -o %t1
// RUN: llvm-objdump --triple=armv7a-none-linux-gnueabi -d --no-show-raw-insn %t | FileCheck %s
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
/// Non-preemptible ifuncs are called via a PLT entry which is always Arm
/// state, expect the ARM callers to go direct to the PLT entry, Thumb
/// branches are indirected via state change thunks, the bl is changed to blx.
.syntax unified
.text
.balign 0x1000
[ELF] Keep st_type for symbol assignment PR46970: for `alias = aliasee`, the alias can be used in relocation processing and on ARM st_type does affect Thumb interworking. It is thus desirable for the alias to get the same st_type. Note that the st_size field should not be inherited because some tools use st_size=0 as a heuristic to detect aliases. Retaining st_size can thwart such heuristics and cause aliases to be preferred over the original symbols. Differential Revision: https://reviews.llvm.org/D86263
2020-08-21 07:05:27 +08:00
.ifdef ALIAS
.type foo1 STT_GNU_IFUNC
.globl foo1
foo1:
.else
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
.type foo STT_GNU_IFUNC
.globl foo
foo:
[ELF] Keep st_type for symbol assignment PR46970: for `alias = aliasee`, the alias can be used in relocation processing and on ARM st_type does affect Thumb interworking. It is thus desirable for the alias to get the same st_type. Note that the st_size field should not be inherited because some tools use st_size=0 as a heuristic to detect aliases. Retaining st_size can thwart such heuristics and cause aliases to be preferred over the original symbols. Differential Revision: https://reviews.llvm.org/D86263
2020-08-21 07:05:27 +08:00
.endif
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
bx lr
.section .text.1, "ax", %progbits
.arm
.global _start
_start:
b foo
bl foo
.section .text.2, "ax", %progbits
.thumb
.global thumb_caller
thumb_caller:
b foo
b.w foo
bl foo
[ELF][test] Fix some llvm-objdump RUN lines which don't actually test anything
2020-08-20 13:48:28 +08:00
// CHECK: 00021004 <_start>:
[ARMInstPrinter] Print the target address of a branch instruction This follows other patches that changed printing immediate values of branch instructions to target addresses, see D76580 (x86), D76591 (PPC), D77853 (AArch64). As observing immediate values might sometimes be useful, they are printed as comments for branch instructions. // llvm-objdump -d output (before) 000200b4 <_start>: 200b4: ff ff ff fa blx #-4 <thumb> 000200b8 <thumb>: 200b8: ff f7 fc ef blx #-8 <_start> // llvm-objdump -d output (after) 000200b4 <_start>: 200b4: ff ff ff fa blx 0x200b8 <thumb> @ imm = #-4 000200b8 <thumb>: 200b8: ff f7 fc ef blx 0x200b4 <_start> @ imm = #-8 // GNU objdump -d. 000200b4 <_start>: 200b4: faffffff blx 200b8 <thumb> 000200b8 <thumb>: 200b8: f7ff effc blx 200b4 <_start> Differential Revision: https://reviews.llvm.org/D104701
2021-06-30 17:34:52 +08:00
// CHECK-NEXT: b 0x21030
// CHECK-NEXT: bl 0x21030
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
[ELF][test] Fix some llvm-objdump RUN lines which don't actually test anything
2020-08-20 13:48:28 +08:00
// CHECK: 0002100c <thumb_caller>:
[ARMInstPrinter] Print the target address of a branch instruction This follows other patches that changed printing immediate values of branch instructions to target addresses, see D76580 (x86), D76591 (PPC), D77853 (AArch64). As observing immediate values might sometimes be useful, they are printed as comments for branch instructions. // llvm-objdump -d output (before) 000200b4 <_start>: 200b4: ff ff ff fa blx #-4 <thumb> 000200b8 <thumb>: 200b8: ff f7 fc ef blx #-8 <_start> // llvm-objdump -d output (after) 000200b4 <_start>: 200b4: ff ff ff fa blx 0x200b8 <thumb> @ imm = #-4 000200b8 <thumb>: 200b8: ff f7 fc ef blx 0x200b4 <_start> @ imm = #-8 // GNU objdump -d. 000200b4 <_start>: 200b4: faffffff blx 200b8 <thumb> 000200b8 <thumb>: 200b8: f7ff effc blx 200b4 <_start> Differential Revision: https://reviews.llvm.org/D104701
2021-06-30 17:34:52 +08:00
// CHECK-NEXT: b.w 0x21018 <__Thumbv7ABSLongThunk_foo>
// CHECK-NEXT: b.w 0x21018 <__Thumbv7ABSLongThunk_foo>
// CHECK-NEXT: blx 0x21030
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
[ELF][test] Fix some llvm-objdump RUN lines which don't actually test anything
2020-08-20 13:48:28 +08:00
// CHECK: 00021018 <__Thumbv7ABSLongThunk_foo>:
// CHECK-NEXT: movw r12, #4144
// CHECK-NEXT: movt r12, #2
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
// CHECK-NEXT: bx r12
// CHECK: Disassembly of section .iplt:
[ELF][test] Fix some llvm-objdump RUN lines which don't actually test anything
2020-08-20 13:48:28 +08:00
// CHECK: 00021030 <$a>:
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
// CHECK-NEXT: add r12, pc, #0, #12
[ELF][test] Fix some llvm-objdump RUN lines which don't actually test anything
2020-08-20 13:48:28 +08:00
// CHECK-NEXT: add r12, r12, #16, #20
[LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbols ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474
2020-01-24 03:03:25 +08:00
// CHECK-NEXT: ldr pc, [r12, #8]!