This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [AArch64/bfd/2.24] relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against
- From: Richard Henderson <rth at redhat dot com>
- To: David Abdurachmanov <david dot abdurachmanov at gmail dot com>
- Cc: binutils at sourceware dot org, Richard Earnshaw <rearnsha at arm dot com>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Wed, 16 Jul 2014 10:06:19 -0700
- Subject: Re: [AArch64/bfd/2.24] relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against
- Authentication-results: sourceware.org; auth=none
- References: <B98BFD30-327B-47F6-94F3-CAD15DD20917 at gmail dot com>
On 07/11/2014 01:19 PM, David Abdurachmanov wrote:
> libcvmfs.a(libcvmfs.a_pub.o): In function `TryArgumentFormatter':
> :(.text+0x77044): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
Was this libcvmfs.a_pub.o created via ld -r? I'm curious because libcvmfs.a
only has one object file in it.
The aarch64 linker backend appears to be buggy in that it does not handle
creating GOT entries for local symbols (h == NULL). In fact, it *silently*
does nothing with them, passing through the original symbol address unchanged.
Which is worse than erroring out earlier -- if your symbols had instead been
accidentally aligned, the link would have succeeded but with incorrect
relocations applied.
I presume that someone thought that this case could never happen, because gcc
isn't supposed to create GOT references to local symbols.
But if one were to massage the object files after the fact, with ld -r and/or
objcopy --localize-symbol, one can produce an object file that the current
linker simply cannot handle.
r~