This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions with binutils 2.24/2.25?
- From: Steve Vormwald <sdvormwa at cray dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 5 Sep 2017 16:51:45 +0000
- Subject: Re: Invalid R_X86_64_GOTPCREL -> R_X86_64_PC32 conversions with binutils 2.24/2.25?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=sdvormwa at cray dot com;
- References: <CAMe9rOrV6Cc-FG3j1XiDX0ZiSZ-DhUQK1DuLAycaE5Q4NweW_Q@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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?
Steven Vormwald
________________________________________
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.