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.

53 lines
1.2 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
[test] lld/test/: change llvm-objdump single-dash long options to double-dash options
2020-03-16 08:47:44 +08:00
// RUN: llvm-objdump --triple=armv7a-none-linux-gnueabi -d --no-show-raw-insn %t
[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
.type foo STT_GNU_IFUNC
.globl foo
foo:
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
// CHECK: 00012004 _start:
// CHECK-NEXT: b #36
// CHECK-NEXT: bl #32
// CHECK: 0001200c thumb_caller:
// CHECK-NEXT: b.w #8
// CHECK-NEXT: b.w #4
// CHECK-NEXT: blx #24
// CHECK: 00012018 __Thumbv7ABSLongThunk_foo:
// CHECK-NEXT: movw r12, #8240
// CHECK-NEXT: movt r12, #1
// CHECK-NEXT: bx r12
// CHECK: Disassembly of section .iplt:
// CHECK: 00012030 $a:
// CHECK-NEXT: add r12, pc, #0, #12
// CHECK-NEXT: add r12, r12, #4096
// CHECK-NEXT: ldr pc, [r12, #8]!