[AArch64/bfd/2.24] relocation truncated to fit: R_AARCH64_LD64_GOT_LO12

Discussion:

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

David Abdurachmanov

2014-07-11 20:19:55 UTC

Hi,

Tested on Fedora 19 Remix aarch64 (GCC 4.8.1, binutils 2.23.52.0.1-9.fc19 20130226) and June 28 Fedora 21 (rawhide) (GCC 4.9.0, binutils 2.24). Default linker if bfd.

I am building a package called CVMFS. It depends on pacparser, which internally depends on Mozilla's SpiderMonkey JS engine.

The packages compiles on i386, x86_64, and armv7hl for Fedora 19 and 20.

I got these linker errors:

libcvmfs.a(libcvmfs.a_pub.o): In function `TryArgumentFormatter':
:(.text+0x77044): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_ConvertArgumentsVA':
:(.text+0x77230): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_ConvertValue':
:(.text+0x78630): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_EnumerateResolvedStandardClasses':
:(.text+0x85000): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_InitObjectClass'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_GetScopeChain':
:(.text+0x8512c): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_LockGCThing':
:(.text+0x85530): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_UnlockGCThing':
:(.text+0x855a8): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_InstanceOf':
:(.text+0x862c4): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_GetConstructor':
:(.text+0x86948): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_SealObject':
:(.text+0x86adc): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
libcvmfs.a(libcvmfs.a_pub.o): In function `JS_AliasProperty':
:(.text+0x87560): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[2]: *** [cvmfs/test_libcvmfs] Error 1

All these functions are in jsapi.o. Other object files contains code calling the same functions [js_GetErrorMessage, js_InitObjectClass] and none of them are reported.

./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000000094 t TryArgumentFormatter
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000022c T JS_ConvertArgumentsVA
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000001558 T JS_ConvertValue
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000df1c T JS_EnumerateResolvedStandardClasses
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000e204 T JS_GetScopeChain
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000e600 T JS_LockGCThing
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000e674 T JS_UnlockGCThing
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000f29c T JS_InstanceOf
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000f90c T JS_GetConstructor
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000fb18 T JS_SealObject
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000010504 T JS_AliasProperty

./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jscntxt.o
000000000000219c T js_GetErrorMessage

./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsobj.o
000000000000577c T js_InitObjectClass

I uploaded the and object file and a static library, which failed to link:

davidlt.web.cern.ch/davidlt/testcase1.tar.bz2

Compiling:

c++ test_libcvmfs.cc.o -o test_libcvmfs libcvmfs.a -lssl -lcrypto -lrt -lpthread -ldl

If more details are needed, reply.

david

Andreas Schwab

2014-07-11 20:35:03 UTC

Permalink

Post by David Abdurachmanov
:(.text+0x77044): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'

That usually happens when there are conflicting declarations, ie. the
same variable has different types in different translation units. In
other words, this is a bug in the sources, not in the linker.

Andreas.

--
Andreas Schwab, ***@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

David Abdurachmanov

2014-07-12 20:56:21 UTC

Permalink

Post by Andreas Schwab

Post by David Abdurachmanov
:(.text+0x77044): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'

I have some doubts about it. I removed SpiderMonkey from dependencies and
from code, then I had problems with cURL. I updated cURL, then I had different
cURL relocation problem. It always seems to be related to functions, e.g.,
passing a callback (function pointer). It's always R_AARCH64_LD64_GOT_LO12_NC.

The current one:

libcvmfs.a(libcvmfs.a_pub.o): In function `Curl_http':
:(.text+0x8234c): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC
against `Curl_FormReader'

000000000007e20c <Curl_FormReader>:
7e20c: a9bc7bfd stp x29, x30, [sp,#-64]!
7e210: 910003fd mov x29, sp
7e214: a90153f3 stp x19, x20, [sp,#16]

[snip]

0000000000081424 <Curl_http>:
81424: d10443ff sub sp, sp, #0x110
81428: a9047bfd stp x29, x30, [sp,#64]
8142c: 910103fd add x29, sp, #0x40
81430: a90553f3 stp x19, x20, [sp,#80]
81434: a9065bf5 stp x21, x22, [sp,#96]
81438: a90763f7 stp x23, x24, [sp,#112]

[snip]

82338: 94000000 bl 7e1e8 <Curl_FormInit>
8233c: 35001100 cbnz w0, 8255c <Curl_http+0x1138>
82340: f941be60 ldr x0, [x19,#888]
82344: f9002ae0 str x0, [x23,#80]
82348: 90000000 adrp x0, 7e20c <Curl_FormReader>
8234c: f9400000 ldr x0, [x0]
82350: f901c278 str x24, [x19,#896]
82354: f901be60 str x0, [x19,#888]

Relocation section '.rela.text' at offset 0x7c7c70 contains 19929 entries:
Offset Info Type Symbol's Value
Symbol's Name + Addend
000000000008234c 0000145300000138 R_AARCH64_LD64_GOT_LO1 000000000007e20c
Curl_FormReader + 0

That is enough to break it:

c++ test_libcvmfs.cc.o -o test_libcvmfs libcvmfs.a -lssl -lcrypto -lrt
-lpthread -ldl

libcvmfs.a is a "combined" static library of libcvmfs_only.a, libz.a,
libsqlite3.a, libcurl.a, and libcares.a.

Linking them altogether separate works fine (binary [test_libcvmfs] also
works):

c++ test_libcvmfs.cc.o -o test_libcvmfs libcvmfs_only.a libz.a libsqlite3.a
libcurl.a libcares.a -lssl -lcrypto -lrt -lpthread -ldl

What they do is to unpack all static libraries (libcvmfs_only.a, libz.a,
libsqlite3.a, libcurl.a, libcares.a), then merge them all together (ld -r
${OBJECTS} -o ${MERGED_OBJ}) and then keeps the public and weak symbols
(objcopy --keep-global-symbols=$PUBLIC_SYMS
--keep-global-symbols=$tmpdir/W_syms $MERGED_OBJ $MERGED_PUBLIC_OBJ). Then it's
packages in ar archive.

They combine them using combine_libs bash scripts:

combine_libs -public libcvmfs_public_syms.txt libcvmfs.a libz.a libsqlite3.a
libcurl.a libcares.a libcvmfs_only.a

combine_libs bash script is below.

More ideas? I will keep debugging it.

david

#!/bin/sh

set -x

PUBLIC_SYMS=""
if [ "$1" = "-public" ]; then
shift
PUBLIC_SYMS=$1
shift
fi

OUTLIB=$1
shift

OBJECTS=""
TDIRS=""
for inlib; do
inlib_base=`basename $inlib`
tmpdir=${inlib_base}.objdir.$$
TDIRS="$TDIRS $tmpdir"

if ( mkdir $tmpdir &&
cp $inlib $tmpdir/${inlib_base} &&
cd $tmpdir &&
ar x $inlib_base &&
rm $inlib_base ); then
OBJECTS="${OBJECTS} `ls $tmpdir/*`"
else
echo "Failed to extract $inlib for $OUTLIB."
exit 1
fi
done

# if a file containing a list of public symbols was specified, merge
# all the objects together and localize all non-public symbols
if [ "$PUBLIC_SYMS" != "" ]; then
tmpdir=${OUTLIB}.objdir.$$
TDIRS="$TDIRS $tmpdir"

MERGED_OBJ=$tmpdir/`basename $OUTLIB`.o
MERGED_PUBLIC_OBJ=$tmpdir/`basename $OUTLIB`_pub.o

# Note that we avoid localizing weak global symbols, because doing so
# causes STL stuff to fail when the library is linked.
if ( mkdir $tmpdir &&
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); then

# we just need this one merged object file
OBJECTS=$MERGED_PUBLIC_OBJ
else
echo "Failed to produce merged public object for $OUTLIB."
exit 1
fi
fi

rm -f $OUTLIB
ar r $OUTLIB ${OBJECTS} || exit 1

for dir in $TDIRS; do
rm -rf $dir
done

exit 0

Andreas Schwab

2014-07-13 07:19:04 UTC

Permalink

This is misaligned. R_AARCH64_LD64_GOT_LO12_NC requires 8 byte
alignment.

Andreas.

--
Andreas Schwab, ***@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Richard Henderson

2014-07-16 15:50:22 UTC

Permalink

Post by Andreas Schwab
This is misaligned. R_AARCH64_LD64_GOT_LO12_NC requires 8 byte
alignment.

No, that's a GOT relocation. A GOT entry should always be 8-byte aligned.

You're thinking of R_AARCH64_LDST64_ABS_LO12_NC perhaps?

r~

p***@gmail.com

2014-07-13 07:42:31 UTC

Permalink

Post by David Abdurachmanov
Hi,
Tested on Fedora 19 Remix aarch64 (GCC 4.8.1, binutils 2.23.52.0.1-9.fc19 20130226) and June 28 Fedora 21 (rawhide) (GCC 4.9.0, binutils 2.24). Default linker if bfd.
I am building a package called CVMFS. It depends on pacparser, which internally depends on Mozilla's SpiderMonkey JS engine.
The packages compiles on i386, x86_64, and armv7hl for Fedora 19 and 20.

This could be a bug in gcc too. I had debugged a case in the aarch64 backend where it would change from the small coding model to the tiny one in some cases. I have a fix but I don't have it right now as I am on vacation. I can post it around Tuesday or so. I saw this while using a gcc 4.7 based gcc and with a distro build (I cannot remember the program right now either, maybe python).

Thanks,
Andrew

Post by David Abdurachmanov
:(.text+0x77044): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x77230): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x78630): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x85000): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_InitObjectClass'
:(.text+0x8512c): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x85530): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x855a8): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x862c4): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x86948): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x86adc): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x87560): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[2]: *** [cvmfs/test_libcvmfs] Error 1
All these functions are in jsapi.o. Other object files contains code calling the same functions [js_GetErrorMessage, js_InitObjectClass] and none of them are reported.
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000000094 t TryArgumentFormatter
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000022c T JS_ConvertArgumentsVA
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000001558 T JS_ConvertValue
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000df1c T JS_EnumerateResolvedStandardClasses
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000e204 T JS_GetScopeChain
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000e600 T JS_LockGCThing
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000e674 T JS_UnlockGCThing
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000f29c T JS_InstanceOf
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000f90c T JS_GetConstructor
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
000000000000fb18 T JS_SealObject
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000010504 T JS_AliasProperty
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jscntxt.o
000000000000219c T js_GetErrorMessage
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsobj.o
000000000000577c T js_InitObjectClass
davidlt.web.cern.ch/davidlt/testcase1.tar.bz2
c++ test_libcvmfs.cc.o -o test_libcvmfs libcvmfs.a -lssl -lcrypto -lrt -lpthread -ldl
If more details are needed, reply.
david

David Abdurachmanov

2014-07-14 08:14:51 UTC

Permalink

Post by p***@gmail.com

That would explain it.

But the following should be good enough for 4GB offset (small code model), IIUC.

82348: 90000000 adrp x0, 7e20c <Curl_FormReader>
8234c: f9400000 ldr x0, [x0]

And ldr here takes imm12 unsigned offset. 82348 calculates page address the Curl_FormReader sits, and 8234c offset inside that page. ld.bfd does not complain about 82348 relocation, only about 8234c.

I can test your patch once it arrives. I am watching gcc-patches.

I know that changing code model compiles fine, but fPIC is not supported with mcmode=large. I could compile the code with mcmode=large, but I couldn't run it. This static library needs fPIC.

I can share the static libraries and combine_libs scripts if someone would like to test locally.

To confirm that problem is in GCC I packed Clang 3.4.1 for F19 on aarch64, but that didn't work. Some porting is needed for Clang (will debug it).

@Andreas,
I checked random function addresses and they seems to be 4-byte aligned, not 8-byte.

david

Richard Earnshaw

2014-07-14 15:25:51 UTC

Permalink

These sound like problems with the alignment of the target symbol.
AAELF64 says:

"Relocation types whose names end with “_NC” are non-checking relocation
types. These must not generate diagnostics in case of field overflow.
... Some non-checking relocations may, however, be expected to check for
correct alignment of the result; the notes explain when this is permitted."

Then:
"312 - R_AARCH64_LD64_GOT_LO12_NC G(GDAT(S+A)) Set the LD/ST immediate
field to bits [11:3] of X. No overflow check; check that X&7 = 0"

So this instruction requires that the target symbol be 64-bit aligned.

Post by David Abdurachmanov
:(.text+0x77230): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x78630): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x85000): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_InitObjectClass'
:(.text+0x8512c): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x85530): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x855a8): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x862c4): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x86948): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x86adc): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage'
:(.text+0x87560): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make[2]: *** [cvmfs/test_libcvmfs] Error 1
All these functions are in jsapi.o. Other object files contains code calling the same functions [js_GetErrorMessage, js_InitObjectClass] and none of them are reported.

The other objects may be using accesses with less strict alignment
constraints.

Post by David Abdurachmanov
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jsapi.o
0000000000000094 t TryArgumentFormatter

...

Post by David Abdurachmanov
./src/spidermonkey/js/src/Linux_All_DBG.OBJ/jscntxt.o
000000000000219c T js_GetErrorMessage

And indeed, this symbol is only 32-bit aligned.

As to why this is occurring, you'll need to do more investigation. Is
it the compiler making an assumption that the object is sufficiently
aligned than it has a right to, or is it just a design error in the
software -- ie the compiler has been giving incorrect information about
the target object.

R.

Richard Henderson

2014-07-16 15:55:05 UTC

Permalink

Post by Richard Earnshaw
"312 - R_AARCH64_LD64_GOT_LO12_NC G(GDAT(S+A)) Set the LD/ST immediate
field to bits [11:3] of X. No overflow check; check that X&7 = 0"

As I replied to Andreas, what has the address of S+A have to do with the
alignment of the GOT entry for S+A? Entries in the GOT should *always* be
aligned, or it's a linker bug.

r~

Richard Henderson

2014-07-16 17:06:19 UTC

Permalink

Post by David Abdurachmanov
:(.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~

David Abdurachmanov

2014-07-16 21:52:08 UTC

Permalink

Post by Richard Henderson

Post by David Abdurachmanov
:(.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

Post by Richard Henderson
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~

David Abdurachmanov

2015-04-16 17:21:11 UTC

Permalink

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

I have re-tested it on Fedora 22 for AArch64. Same issue still exist.

I created a tarball (3.1M) with logs and binaries, which should be enough to reproduce the issue.

Bugzilla PR: https://sourceware.org/bugzilla/show_bug.cgi?id=18270

david