maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/AArch64/adrp-relocation.s

19 lines
779 B
ArmAsm
Raw Normal View History

AArch64/ARM64: move ARM64 into AArch64's place This commit starts with a "git mv ARM64 AArch64" and continues out from there, renaming the C++ classes, intrinsics, and other target-local objects for consistency. "ARM64" test directories are also moved, and tests that began their life in ARM64 use an arm64 triple, those from AArch64 use an aarch64 triple. Both should be equivalent though. This finishes the AArch64 merge, and everyone should feel free to continue committing as normal now. llvm-svn: 209577
2014-05-24 20:50:23 +08:00
// RUN: llvm-mc -triple=aarch64-linux-gnu -filetype=obj -o - %s| llvm-readobj -r - | FileCheck %s
AArch64: migrate ADRP relaxation test to be llvm-mc only. llvm-svn: 192281
2013-10-09 15:53:49 +08:00
.text
// These should produce an ADRP/ADD pair to calculate the address of
// testfn. The important point is that LLVM shouldn't think it can deal with the
// relocation on the ADRP itself (even though it knows everything about the
// relative offsets of testfn and foo) because its value depends on where this
// object file's .text section gets relocated in memory.
adrp x0, sym
adrp x0, :got:sym
adrp x0, :gottprel:sym
adrp x0, :tlsdesc:sym
.global sym
sym:
// CHECK: R_AARCH64_ADR_PREL_PG_HI21 sym
// CHECK: R_AARCH64_ADR_GOT_PAGE sym
// CHECK: R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 sym
Update AArch64 ELF relocations to ABI 1.0 This mostly entails adding relocations, however there are a couple of changes to existing relocations: 1. R_AARCH64_NONE is defined to be zero rather than 256 R_AARCH64_NONE has been defined to be zero for a long time elsewhere e.g. binutils and glibc since the submission of the AArch64 port in 2012 so this is required for compatibility. 2. R_AARCH64_TLSDESC_ADR_PAGE renamed to R_AARCH64_TLSDESC_ADR_PAGE21 I don't think there is any way for relocation names to leak out of LLVM so this should not break anything. Tested with check-all with no regressions. llvm-svn: 222821
2014-11-26 18:49:18 +08:00
// CHECK: R_AARCH64_TLSDESC_ADR_PAGE21 sym