Commit Graph

10 Commits

Author SHA1 Message Date
Fangrui Song f0374e7db2 [test] lld/test/: change llvm-objdump single-dash long options to double-dash options 2020-03-15 17:48:36 -07:00
Fangrui Song 81cebfd008 [ELF][test] Change -o %t to -o /dev/null if the output is not needed 2020-02-12 21:54:50 -08:00
Fangrui Song 4a4ce14eb2 [ELF] Mention symbol name in reportRangeError()
For an out-of-range relocation referencing a non-local symbol, report the symbol name and the object file that defines the symbol. As an example:
```
t.o:(function func: .text.func+0x3): relocation R_X86_64_32S out of range: -281474974609120 is not in [-2147483648, 2147483647]
```
=>
```
t.o:(function func: .text.func+0x3): relocation R_X86_64_32S out of range: -281474974609120 is not in [-2147483648, 2147483647]; references func
>>> defined in t1.o
```

Reviewed By: grimar

Differential Revision: https://reviews.llvm.org/D73518
2020-01-29 09:38:25 -08:00
Fangrui Song f66b767abe [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 08:34:56 +00:00
Fangrui Song 2fb6b0f2ba [ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, R_PPC64_ADDR{16,32}, R_X86_64_{8,16}
Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed
value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of
`[-2**(n-1), 2**(n-1))` to check overflows.

The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel.
The new behavior is compatible with ld.bfd's complain_overflow_bitfield.

The upper bound of the error message is not correct. Fix it as well.

The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar.

Reviewed By: ruiu

Differential Revision: https://reviews.llvm.org/D63690

llvm-svn: 364164
2019-06-24 05:37:20 +00:00
Dimitry Andric c9de3b4d26 Align AArch64 and i386 image base to superpage
Summary:

As for x86_64, the default image base for AArch64 and i386 should be
aligned to a superpage appropriate for the architecture.

On AArch64, this is 2 MiB, on i386 it is 4 MiB.

Reviewers: emaste, grimar, javed.absar, espindola, ruiu, peter.smith, srhines, rprichard

Reviewed By: ruiu, peter.smith

Subscribers: jfb, markj, arichardson, krytarowski, kristof.beyls, llvm-commits

Differential Revision: https://reviews.llvm.org/D50297

llvm-svn: 342746
2018-09-21 16:58:13 +00:00
Alexander Richardson d2481bed05 [ELF] When a relocation is out of range print the value and the range
Reviewers: ruiu, grimar

Reviewed By: ruiu

Subscribers: emaste, nemanjai, javed.absar, kbarton, llvm-commits

Differential Revision: https://reviews.llvm.org/D40962

llvm-svn: 320416
2017-12-11 20:47:21 +00:00
Eugene Leviant ee8dcfbdf7 [ELF] Set max page size to 64K for AArch64
Differential revision: https://reviews.llvm.org/D25079

llvm-svn: 283200
2016-10-04 08:58:55 +00:00
Igor Kudrin cfe47f5b32 [ELF/AArch64] Allow only valid dynamic relocations in the output.
All relocations, which cannot be handled by the dynamic linker,
cause a linking error "rebuild with -fPIC".

Differential revision: http://reviews.llvm.org/D15193

llvm-svn: 254840
2015-12-05 06:20:24 +00:00
Igor Kudrin fea8ed50ef [ELF/AArch64] Fix overflow checks for R_AARCH64_{ABS,PREL}{16,32} relocations.
ABI specifies the allowed range for these relocations as 2^(n-1) <= X < 2^n.

The patch fixes checks and introduces precise tests for these relocations.

Differential revision: http://reviews.llvm.org/D14957

llvm-svn: 254146
2015-11-26 10:05:24 +00:00