llvm-project/lld/test/ELF/aarch64-ldprel-lo19-invalid.s

# REQUIRES: aarch64

# RUN: llvm-mc -filetype=obj -triple=aarch64-linux-none %s -o %t.o
# RUN: not ld.lld -shared %t.o -o /dev/null 2>&1 | FileCheck %s

# CHECK: relocation R_AARCH64_LD_PREL_LO19 out of range: 2131192 is not in [-1048576, 1048575]

  ldr x8, patatino
  .data
  .zero 2000000
patatino:
[AArch64] Include test for out of range LD_PREL_LO19. llvm-svn: 313846 2017-09-21 08:16:29 +08:00			`# REQUIRES: aarch64`

			`# RUN: llvm-mc -filetype=obj -triple=aarch64-linux-none %s -o %t.o`
[ELF] Replace unused output filenames with /dev/null in tests Post commit review at rLLD335992 llvm-svn: 336129 2018-07-03 01:48:23 +08:00			`# RUN: not ld.lld -shared %t.o -o /dev/null 2>&1 \| FileCheck %s`
[AArch64] Include test for out of range LD_PREL_LO19. llvm-svn: 313846 2017-09-21 08:16:29 +08:00
[ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges Ported the D64906 technique to AArch64. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an aarch64 binary decreases by at most 192kb. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * musl<=1.1.22 * FreeBSD 13.0-CURRENT (and before) rtld-elf arm64 New test aarch64-tls-vaddr-align.s checks that our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64930 llvm-svn: 369344 2019-08-20 16:34:56 +08:00			`# CHECK: relocation R_AARCH64_LD_PREL_LO19 out of range: 2131192 is not in [-1048576, 1048575]`
[AArch64] Include test for out of range LD_PREL_LO19. llvm-svn: 313846 2017-09-21 08:16:29 +08:00
			`ldr x8, patatino`
			`.data`
			`.zero 2000000`
			`patatino:`