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

H.J. Lu hjl.tools@gmail.com
Tue Sep 5 16:32:00 GMT 2017


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.



More information about the Binutils mailing list