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/global-offset-table-positio...

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

36 lines
780 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] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .got On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - . and produce a relocation that can be processed without needing to know the value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM gcc produces R_ARM_BASE_PREL but clang produces the more general R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of the GOT or end of the GOT dependent on architecture.. If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this change will not be necessary for new objects. However there may still be old objects and versions of clang. Differential Revision: https://reviews.llvm.org/D34355 llvm-svn: 306282
2017-06-26 18:22:17 +08:00
// RUN: llvm-mc -filetype=obj -triple=armv7a-linux-gnueabihf %s -o %t
[ELF] - Do --hash-style=both by default. Its PR34712, GNU linkers recently changed default values to "both" of "sysv". Patch do the same for all targets except MIPS, where .gnu.hash section is not yet supported. Code suggested by Rui Ueyama. Differential revision: https://reviews.llvm.org/D38407 llvm-svn: 315051
2017-10-06 17:37:44 +08:00
// RUN: ld.lld --hash-style=sysv -shared %t -o %t2
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
// RUN: llvm-readobj --symbols %t2 | FileCheck %s
[ELF] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .got On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - . and produce a relocation that can be processed without needing to know the value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM gcc produces R_ARM_BASE_PREL but clang produces the more general R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of the GOT or end of the GOT dependent on architecture.. If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this change will not be necessary for new objects. However there may still be old objects and versions of clang. Differential Revision: https://reviews.llvm.org/D34355 llvm-svn: 306282
2017-06-26 18:22:17 +08:00
[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
/// The ARM _GLOBAL_OFFSET_TABLE_ should be defined at the start of the .got
[ELF] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .got On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - . and produce a relocation that can be processed without needing to know the value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM gcc produces R_ARM_BASE_PREL but clang produces the more general R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of the GOT or end of the GOT dependent on architecture.. If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this change will not be necessary for new objects. However there may still be old objects and versions of clang. Differential Revision: https://reviews.llvm.org/D34355 llvm-svn: 306282
2017-06-26 18:22:17 +08:00
.globl a
.type a,%object
.comm a,4,4
.globl f
.type f,%function
f:
ldr r2, .L1
.L0:
add r2, pc
.L1:
.word _GLOBAL_OFFSET_TABLE_ - (.L0+4)
.word a(GOT)
.global _start
.type _start,%function
_start:
bl f
.data
// CHECK: Name: _GLOBAL_OFFSET_TABLE_
[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: Value: 0x20268
[ELF] Define _GLOBAL_OFFSET_TABLE_ symbol relative to .got On many architectures gcc and clang will recognize _GLOBAL_OFFSET_TABLE_ - . and produce a relocation that can be processed without needing to know the value of _GLOBAL_OFFSET_TABLE_. This is not always the case; for example ARM gcc produces R_ARM_BASE_PREL but clang produces the more general R_ARM_REL32 to _GLOBAL_OFFSET_TABLE_. To evaluate this relocation correctly _GLOBAL_OFFSET_TABLE_ must be defined to be the either the base of the GOT or end of the GOT dependent on architecture.. If/when llvm-mc is changed to recognize _GLOBAL_OFFSET_TABLE_ - . this change will not be necessary for new objects. However there may still be old objects and versions of clang. Differential Revision: https://reviews.llvm.org/D34355 llvm-svn: 306282
2017-06-26 18:22:17 +08:00
// CHECK-NEXT: Size: 0
// CHECK-NEXT: Binding: Local
// CHECK-NEXT: Type: None
// CHECK-NEXT: Other [ (0x2)
// CHECK-NEXT: STV_HIDDEN (0x2)
// CHECK-NEXT: ]
Revert r327248, "For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at" This change broke ARM code that expects to be able to add _GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32. I will provide a reproducer on llvm-commits. llvm-svn: 327688
2018-03-16 09:01:44 +08:00
// CHECK-NEXT: Section: .got