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-no-undefined-thunk.s

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

26 lines
658 B
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] Do not create interworking thunks for undefined weak references. An undefined weak reference is given an address of 0 this will incorrectly trigger the creation of a Thumb to ARM interworking Thunk if there is a Thumb branch instruction to the symbol. This results in an error as Thunks only make sense to defined or shared symbols. We prevent this by detecting an undefined symbol and not creating a thunk for it. Differential Revision: https://reviews.llvm.org/D26239 llvm-svn: 285896
2016-11-03 19:49:23 +08:00
// RUN: llvm-mc -filetype=obj -triple=thumbv7a-none-linux-gnueabi %s -o %t
[ARM][test] Improve tests Delete trailing 2>&1 that is not piped to another command. Add --no-show-raw-insn to objdump -d commands. llvm-svn: 366676
2019-07-22 19:37:03 +08:00
// RUN: ld.lld %t -o %t2
[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=thumbv7a-none-linux-gnueabi -d %t2 | FileCheck %s
[ELF] Do not create interworking thunks for undefined weak references. An undefined weak reference is given an address of 0 this will incorrectly trigger the creation of a Thumb to ARM interworking Thunk if there is a Thumb branch instruction to the symbol. This results in an error as Thunks only make sense to defined or shared symbols. We prevent this by detecting an undefined symbol and not creating a thunk for it. Differential Revision: https://reviews.llvm.org/D26239 llvm-svn: 285896
2016-11-03 19:49:23 +08:00
// Check that no thunks are created for an undefined weak symbol
.syntax unified
.weak target
.section .text.thumb, "ax", %progbits
.thumb
.global
_start:
bl target
b target
b.w target
// 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: <_start>:
[ELF][ARM] Allow PT_LOAD to have overlapping p_offset ranges on EM_ARM Port the D64906 technique to ARM. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an arm binary decreases by at most 12kb. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66749 llvm-svn: 370049
2019-08-27 19:52:36 +08:00
// 0x110b8 = next instruction
[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: 200b4: {{.*}} bl #0
// CHECK-NEXT: 200b8: {{.*}} b.w #0 <_start+0x8>
// CHECK-NEXT: 200bc: {{.*}} b.w #0 <_start+0xc>