[Bug ld/32591] undue GOTPCREL relaxation attempts

[i at maskray dot me]

https://sourceware.org/bugzilla/show_bug.cgi?id=32591

Fangrui Song <i at maskray dot me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |i at maskray dot me

--- Comment #4 from Fangrui Song <i at maskray dot me> ---
I feel that we should have a pass to revert GOT optimization decision instead
of adding a special case -z no-relax=...

> The main problem appears to be that at the time the decision is taken whether 
> to relax certain insns (and into which alternative forms), we don't know yet 
> whether the replacement relocs would end up overflowing. Thus, unless the 
> whole determination can be moved (much?) later, the only choice would look to 
> be to undo the transformations (perhaps just partly, i.e. after initially 
> converting to MOV-from-immediate, replace that by the less restrictive 
> RIP-relative LEA; nothing similar is of course possible for arithmetic insns 
> we convert). Which would of course require there to be enough information to 
> restore what had been there originally (I haven't thoroughly checked yet 
> whether that's the case).

In 2023, lld implemented a pass during section layout, after relocation
scanning, to revert GOTPCRELX optimization decisions that would lead to
oveflows.
https://reviews.llvm.org/D157020 introduced a test that can be used to
demonstrate BFD's behavior as well.      x86-64-gotpc-relax-too-far.s

R_390_GOTENT for s390x adopted this `relaxOne` after relocation scanning
(https://github.com/llvm/llvm-project/pull/75643).

% cd ~/llvm/lld/test/ELF
% ff x86-64-gotpc-relax-too-far.s  #
https://github.com/MaskRay/Config/blob/master/home/bin/ff
2  split-file x86-64-gotpc-relax-too-far.s a
3  llvm-mc -filetype=obj -triple=x86_64 a/a.s -o a/a.o
4  ld.lld -T a/lds1 a/a.o -o a/bin
5  llvm-objdump -d a/bin | FileCheck --check-prefix=DISASM
x86-64-gotpc-relax-too-far.s
6  llvm-readelf -S a/bin | FileCheck --check-prefixes=GOT
x86-64-gotpc-relax-too-far.s
7  ld.lld -T a/lds2 a/a.o -o a/bin2
8  llvm-objdump -d a/bin2 | FileCheck --check-prefix=DISASM
x86-64-gotpc-relax-too-far.s
9  llvm-readelf -S a/bin2 | FileCheck --check-prefixes=GOT
x86-64-gotpc-relax-too-far.s
10 ld.lld -T a/lds3 a/a.o -o a/bin3
11 llvm-readelf -S a/bin3 | FileCheck --check-prefixes=UNNECESSARY-GOT
x86-64-gotpc-relax-too-far.s
12 ld.lld -T a/lds4 a/a.o -o a/bin4
13 llvm-objdump -d a/bin4 | FileCheck --check-prefix=DISASM4
x86-64-gotpc-relax-too-far.s
% ld.bfd -T a/lds1 a/a.o
a/a.o: in function `_start':
(.text+0x9): failed to convert GOTPCREL relocation against '__stop_data';
relink with --no-relax
(.text+0x10): failed to convert GOTPCREL relocation against '__stop_data';
relink with --no-relax
% ld.bfd -T a/lds4 a/a.o
a/a.o: in function `_start':
(.text+0x9): failed to convert GOTPCREL relocation against '__stop_data';
relink with --no-relax
(.text+0x10): failed to convert GOTPCREL relocation against '__stop_data';
relink with --no-relax

The tests modified by
https://github.com/llvm/llvm-project/commit/f3c4dae6f2c44f1a7f130c4cf4b2861b62402b48
("[ELF] -no-pie: don't optimize addq R_X86_64_REX_GOTPCRELX when
!isInt<32>(va)")
might be relevant as well, but I haven't tested them on BFD.

-- 
You are receiving this mail because:
You are on the CC list for the bug.