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-shared.s

56 lines
2.3 KiB
ArmAsm
Raw Normal View History

[ELF] Move `// REQUIRES:` line to the top llvm-svn: 335676
2018-06-27 06:20:04 +08:00
// REQUIRES: arm
[ELF] Add support for Armv5 and Armv6 compatible Thunks Older Arm architectures do not support the MOVT and MOVW instructions so we must use an alternative sequence of instructions to transfer control to the destination. Assuming at least Armv5 this patch adds support for Thunks that load or add to the program counter. Note that there are no Armv5 Thumb Thunks as there is no Thumb branch instruction in Armv5 that supports Thunks. These thunks will not work for Armv4t (arm7tdmi) as this architecture cannot change state from using the LDR or ADD instruction. Differential Revision: https://reviews.llvm.org/D50077 llvm-svn: 340160
2018-08-20 17:37:50 +08:00
// RUN: llvm-mc -arm-add-build-attributes -filetype=obj -triple=thumbv7a-none-linux-gnueabi %s -o %t
[ELF] Add support for thunks to undefined non-weak symbols In a shared library an undefined symbol is implicitly imported. If the symbol is called as a function a PLT entry is generated for it. When the caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT entries are in ARM state. This change allows undefined symbols to have thunks in the same way that shared symbols may have thunks. llvm-svn: 290951
2017-01-04 17:45:45 +08:00
// RUN: ld.lld %t --shared -o %t.so
// RUN: llvm-objdump -d -triple=thumbv7a-none-linux-gnueabi %t.so | FileCheck %s
.syntax unified
.global sym1
.global elsewhere
.weak weakref
sym1:
b.w elsewhere
b.w weakref
// Check that we generate a thunk for an undefined symbol called via a plt
// entry.
// CHECK: Disassembly of section .text:
[llvm-objdump] Print newlines before and after "Disassembly of section ...:" This improves readability and the behavior is consistent with GNU objdump. The new test test/tools/llvm-objdump/X86/disassemble-section-name.s checks we print newlines before and after "Disassembly of section ...:" Differential Revision: https://reviews.llvm.org/D61127 llvm-svn: 359668
2019-05-01 18:40:48 +08:00
// CHECK-EMPTY:
[ELF] Add support for thunks to undefined non-weak symbols In a shared library an undefined symbol is implicitly imported. If the symbol is called as a function a PLT entry is generated for it. When the caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT entries are in ARM state. This change allows undefined symbols to have thunks in the same way that shared symbols may have thunks. llvm-svn: 290951
2017-01-04 17:45:45 +08:00
// CHECK-NEXT: sym1:
[ELF] Rename ARM Thunks in anticipation of Range Thunks The existing names for the ARM and Thumb Thunks highlight their current use as interworking Thunks. These Thunks can also be used for range extension Thunks where there is no state change. This change makes the name more generic so it is suitable for range extension. Differential Revision: https://reviews.llvm.org/D31605 llvm-svn: 299418
2017-04-04 17:29:36 +08:00
// CHECK-NEXT: 1000: 00 f0 02 b8 b.w #4 <__ThumbV7PILongThunk_elsewhere>
// CHECK-NEXT: 1004: 00 f0 06 b8 b.w #12 <__ThumbV7PILongThunk_weakref>
// CHECK: __ThumbV7PILongThunk_elsewhere:
[ELF] Optimize Arm PLT sequences A more efficient PLT sequence can be used when the distance between the .plt and the end of the .plt.got is less than 128 Megabytes, which is frequently true. We fall back to the old sequence when the offset is larger than 128 Megabytes. This gives us an alternative to forcing the longer entries with --long-plt as we gracefully fall back to it as needed. See ELF for the ARM Architecture Appendix A for details of the PLT sequence. Differential Revision: https://reviews.llvm.org/D41246 llvm-svn: 320987
2017-12-18 22:46:27 +08:00
// CHECK-NEXT: 1008: 40 f2 2c 0c movw r12, #44
[ELF] Add support for thunks to undefined non-weak symbols In a shared library an undefined symbol is implicitly imported. If the symbol is called as a function a PLT entry is generated for it. When the caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT entries are in ARM state. This change allows undefined symbols to have thunks in the same way that shared symbols may have thunks. llvm-svn: 290951
2017-01-04 17:45:45 +08:00
// CHECK-NEXT: 100c: c0 f2 00 0c movt r12, #0
// CHECK-NEXT: 1010: fc 44 add r12, pc
// CHECK-NEXT: 1012: 60 47 bx r12
[ELF] Rename ARM Thunks in anticipation of Range Thunks The existing names for the ARM and Thumb Thunks highlight their current use as interworking Thunks. These Thunks can also be used for range extension Thunks where there is no state change. This change makes the name more generic so it is suitable for range extension. Differential Revision: https://reviews.llvm.org/D31605 llvm-svn: 299418
2017-04-04 17:29:36 +08:00
// CHECK: __ThumbV7PILongThunk_weakref:
[ELF] Optimize Arm PLT sequences A more efficient PLT sequence can be used when the distance between the .plt and the end of the .plt.got is less than 128 Megabytes, which is frequently true. We fall back to the old sequence when the offset is larger than 128 Megabytes. This gives us an alternative to forcing the longer entries with --long-plt as we gracefully fall back to it as needed. See ELF for the ARM Architecture Appendix A for details of the PLT sequence. Differential Revision: https://reviews.llvm.org/D41246 llvm-svn: 320987
2017-12-18 22:46:27 +08:00
// CHECK-NEXT: 1014: 40 f2 30 0c movw r12, #48
[ELF] Add support for thunks to undefined non-weak symbols In a shared library an undefined symbol is implicitly imported. If the symbol is called as a function a PLT entry is generated for it. When the caller is a Thumb b.w a thunk to the PLT entry is needed as all PLT entries are in ARM state. This change allows undefined symbols to have thunks in the same way that shared symbols may have thunks. llvm-svn: 290951
2017-01-04 17:45:45 +08:00
// CHECK-NEXT: 1018: c0 f2 00 0c movt r12, #0
// CHECK-NEXT: 101c: fc 44 add r12, pc
// CHECK-NEXT: 101e: 60 47 bx r12
[ELF][ARM] Simplify some llvm-objdump tests with both ARM/Thumb states llvm-objdump can switch between ARM/Thumb states after D60927. In a few lld tests, we run both * llvm-objdump -d -triple=thumbv7a-none-linux-gnueabi %t * llvm-objdump -d -triple=armv7a-none-linux-gnueabi %t to test ARM/Thumb parts of the same file. In many cases we can just run one command. There is a problem that prevents us from cleaning more tests (e.g. test/ELF/arm-thumb-interwork-thunk.s): In llvm-objdump, while we have ARM/Thumb (primary and secondary) MCDisassembler and MCSubtargetInfo, we have just one MCInstrAnalysis which is used to resolve the targets of calls in both ARM/Thumb parts. // ThumbMCInstrAnalysis evaluating ARM parts or ARMMCInstrAnalysis evaluating Thumb parts // will have incorrect offsets. // An example of llvm-objdump -d -triple=thumbv7a on ARM part: 1304: 3d ff ff fa blx #-780 # no <...> 1308: 06 00 00 ea b #24 <arm_caller+0x24> # wrong target due to wrong offset Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D66539 llvm-svn: 369535
2019-08-21 23:30:55 +08:00
// CHECK: Disassembly of section .plt:
// CHECK-EMPTY:
// CHECK-NEXT: $a:
// CHECK-NEXT: 1020: 04 e0 2d e5 str lr, [sp, #-4]!
// CHECK-NEXT: 1024: 00 e6 8f e2 add lr, pc, #0, #12
// CHECK-NEXT: 1028: 01 ea 8e e2 add lr, lr, #4096
// CHECK-NEXT: 102c: dc ff be e5 ldr pc, [lr, #4060]!
// CHECK: $d:
// CHECK-NEXT: 1030: d4 d4 d4 d4 .word 0xd4d4d4d4
// CHECK-NEXT: 1034: d4 d4 d4 d4 .word 0xd4d4d4d4
// CHECK-NEXT: 1038: d4 d4 d4 d4 .word 0xd4d4d4d4
// CHECK-NEXT: 103c: d4 d4 d4 d4 .word 0xd4d4d4d4
// CHECK: $a:
// CHECK-NEXT: 1040: 00 c6 8f e2 add r12, pc, #0, #12
// CHECK-NEXT: 1044: 01 ca 8c e2 add r12, r12, #4096
// CHECK-NEXT: 1048: c4 ff bc e5 ldr pc, [r12, #4036]!
// CHECK: $d:
// CHECK-NEXT: 104c: d4 d4 d4 d4 .word 0xd4d4d4d4
// CHECK: $a:
// CHECK-NEXT: 1050: 00 c6 8f e2 add r12, pc, #0, #12
// CHECK-NEXT: 1054: 01 ca 8c e2 add r12, r12, #4096
// CHECK-NEXT: 1058: b8 ff bc e5 ldr pc, [r12, #4024]!
// CHECK: $d:
// CHECK-NEXT: 105c: d4 d4 d4 d4 .word 0xd4d4d4d4