Re: Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions with binutils 2.24/2.25?

[Steve Vormwald <sdvormwa at cray dot com>]

That looks great.

Steven Vormwald
________________________________________
From: H.J. Lu <hjl.tools@gmail.com>
Sent: Tuesday, September 5, 2017 12:19:52 PM
To: Steve Vormwald
Cc: Binutils
Subject: Re: Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions with binutils 2.24/2.25?

On Tue, Sep 5, 2017 at 9:51 AM, Steve Vormwald <sdvormwa@cray.com> wrote:
> I don't see any problems with adding an option to control this behavior.  The current error message is very confusing though when the object file in question doesn't contain any R_X86_64_PC32 relocations.  Is it possible to note that the error is/may be due to such a transformation, or at least hint that the user might try the --no-relax option?
>

Good point.  How this?

[hjl@gnu-6 pr18591]$ cat x.S
.hidden foo
.comm pad,0x80000000,8
.comm foo,8,8
.text
.globl bar
.type bar, @function
bar:
movq foo@GOTPCREL(%rip), %rax
[hjl@gnu-6 pr18591]$ make
gcc    -c -o x.o x.S
./ld -z max-page-size=0x200000 -shared -o x.so x.o
./ld: failed to convert GOTPCREL relocation; relink with --no-releax
make: *** [Makefile:25: x.so] Error 1
[hjl@gnu-6 pr18591]$

> ________________________________________
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Tuesday, September 5, 2017 11:32:08 AM
> To: Steve Vormwald; Binutils
> Subject: Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions with binutils 2.24/2.25?
>
> Hi Steve,
>
> I am revisiting your issue:
>
> ---
> When updating from binutils 2.23 to 2.25, we have run into "truncated to fit:
> R_X86_64_PC32 against symbol" errors for symbols that only have
> R_X86_64_GOTPCREL relocations.  One of the object files that is being linked
> contains a handful of large arrays that end up being placed more than 2GB away
> from the text that references them, hence the use of R_X86_64_GOTPCREL
> relocations rather than "simpler" relocations with offset limitations.  It
> looks like the linker is automatically converting these back to a relocation
> with stricter distance limits due to mod
> 80d873266deca488bd8059e32780e8ce3ef6191d (Convert mov to lea for loading local
> function address).  Are we misusing R_X86_64_GOTPCREL or is this an ld bug?
> ---
>
> The current solution doesn't work correctly 100% and prevents other
> linker improvements.
> I'd like to change it with a linker option, --no-relax.  This is by
> default, you will get a linker
> error:
>
> # /export/build/gnu/binutils/build-x86_64-linux/ld/ld-new -z
> max-page-size=0x200000 -shared -o x.so x.o
> x.o: In function `_start':
> (.text+0x3): relocation truncated to fit: R_X86_64_PC32 against symbol
> `foo' defined in .data section in x.o
> /export/build/gnu/binutils/build-x86_64-linux/ld/ld-new: relink with --no-releax
>
> Adding --no-relax avoids the linker error:
>
> # /export/build/gnu/binutils/build-x86_64-linux/ld/ld-new -z
> max-page-size=0x200000 -shared -o x.so x.o --no-relax
> #
>
> --
> H.J.



--
H.J.