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

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

61 lines
2.1 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
[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 -d --no-show-raw-insn --triple=thumbv7a-none-linux-gnueabi %t.so | FileCheck %s
[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
.syntax unified
.global sym1
.global elsewhere
.weak weakref
sym1:
b.w elsewhere
b.w weakref
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
bl elsewhere
bl weakref
[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 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:
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK-NEXT: <sym1>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 101e0: b.w #12 <__ThumbV7PILongThunk_elsewhere>
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: b.w #20 <__ThumbV7PILongThunk_weakref>
// CHECK-NEXT: blx #68
// CHECK-NEXT: blx #80
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <__ThumbV7PILongThunk_elsewhere>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 101f0: movw r12, #52
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: movt r12, #0
// CHECK-NEXT: add r12, pc
// CHECK-NEXT: bx r12
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <__ThumbV7PILongThunk_weakref>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 101fc: movw r12, #56
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: movt r12, #0
// CHECK-NEXT: add r12, pc
// CHECK-NEXT: bx r12
[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
[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:
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK-NEXT: <$a>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 10210: str lr, [sp, #-4]!
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: add lr, pc, #0, #12
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: add lr, lr, #32
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: ldr pc, [lr, #148]!
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <$d>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 10220: d4 d4 d4 d4 .word 0xd4d4d4d4
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: .word 0xd4d4d4d4
// CHECK-NEXT: .word 0xd4d4d4d4
// CHECK-NEXT: .word 0xd4d4d4d4
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <$a>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 10230: add r12, pc, #0, #12
// CHECK-NEXT: add r12, r12, #32
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: ldr pc, [r12, #124]!
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <$d>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 1023c: d4 d4 d4 d4 .word 0xd4d4d4d4
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <$a>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 10240: add r12, pc, #0, #12
// CHECK-NEXT: add r12, r12, #32
[ELF][ARM][test] Keep arm-thumb-interwork-shared.s The revert of D73542 (c29003813ab9bd6ea7b6de40ea8f1fe21979f13f) deleted the newly added tests to arm-thumb-interwork-shared.s . We should keep them.
2020-02-08 01:43:40 +08:00
// CHECK-NEXT: ldr pc, [r12, #112]!
[llvm-objdump] -d: print `00000000 <foo>:` instead of `00000000 foo:` The new behavior matches GNU objdump. A pair of angle brackets makes tests slightly easier. `.foo:` is not unique and thus cannot be used in a `CHECK-LABEL:` directive. Without `-LABEL`, the CHECK line can match the `Disassembly of section` line and causes the next `CHECK-NEXT:` to fail. ``` Disassembly of section .foo: 0000000000001634 .foo: ``` Bdragon: <> has metalinguistic connotation. it just "feels right" Reviewed By: rupprecht Differential Revision: https://reviews.llvm.org/D75713
2020-03-06 06:18:38 +08:00
// CHECK: <$d>:
[ELF][ARM] Increase default max-page-size from 4096 to 6536 See http://lists.llvm.org/pipermail/llvm-dev/2020-April/140549.html For the record, GNU ld changed to 64k max page size in 2014 https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=7572ca8989ead4c3425a1500bc241eaaeffa2c89 "[RFC] ld/ARM: Increase maximum page size to 64kB" Android driver forced 4k page size in AArch64 (D55029) and ARM (D77746). A binary linked with max-page-size=4096 does not run on a system with a higher page size configured. There are some systems out there that do this and it leads to the binary getting `Killed!` by the kernel. In the non-linker-script cases, when linked with -z noseparate-code (default), the max-page-size increase should not cause any size difference. There may be some VMA usage differences, though. Reviewed By: psmith, MaskRay Differential Revision: https://reviews.llvm.org/D77330
2020-04-18 23:06:37 +08:00
// CHECK-NEXT: 1024c: d4 d4 d4 d4 .word 0xd4d4d4d4