Re: [AArch64/bfd/2.24] relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against

[David Abdurachmanov <david dot abdurachmanov at gmail dot com>]

On Jul 16, 2014, at 7:06 PM, Richard Henderson wrote:

> 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.

Correct. The script of how it's combined are provided in this thread.

They unpack all static libraries (zlib, curl, pacparser, etc.) Then combine all object files into one with ld -r. The uses objcopy to only copy specific parts (public CVMFS API + all weak symbols). Then pack in back with ar (that's why a single object file).

The last time I looked, not doing `objcopy` provides a working library. 

The original combining script does:

ld -r ${OBJECTS} -o ${MERGED_OBJ} &&
( nm ${MERGED_OBJ} | awk ' $2 == "W" {print $3}' | sort | uniq > $tmpdir/W_syms ) &&
objcopy --keep-global-symbols=$PUBLIC_SYMS --keep-global-symbols=$tmpdir/W_syms $MERGED_OBJ $MERGED_PUBLIC_OBJ

If you just do:

ld -r ${OBJECTS} -o ${MERGED_OBJ})

All works fine.

I can pack zlib, curl, parparser static libraries, the combining script and the test if you want to check it locally.

david

> 
> 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~