Discussion started 2014 July: https://sourceware.org/ml/binutils/2014-07/msg00130.html Noticed while building CVMFS on Fedora 22 AArch64: https://ecsft.cern.ch/dist/cvmfs/cvmfs-2.1.20/cvmfs-2.1.20-1.fc21.src.rpm [root@ubuntu ~]# gcc -dumpversion 5.0.1 [root@ubuntu ~]# ld -v GNU ld version 2.25-5.fc22 ## ERRORS ## libcvmfs.a(libcvmfs.a_pub.o): In function `TryArgumentFormatter': wpad.cc:(.text+0x840d8): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_ConvertArgumentsVA': wpad.cc:(.text+0x842c4): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_ConvertValue': wpad.cc:(.text+0x857f4): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_EnumerateResolvedStandardClasses': wpad.cc:(.text+0x92250): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_InitObjectClass' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_GetScopeChain': wpad.cc:(.text+0x92388): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_LockGCThing': wpad.cc:(.text+0x927ac): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_UnlockGCThing': wpad.cc:(.text+0x92828): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_InstanceOf': wpad.cc:(.text+0x9358c): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_GetConstructor': wpad.cc:(.text+0x93c20): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_SealObject': wpad.cc:(.text+0x93dbc): relocation truncated to fit: R_AARCH64_LD64_GOT_LO12_NC against `js_GetErrorMessage' libcvmfs.a(libcvmfs.a_pub.o): In function `JS_AliasProperty': wpad.cc:(.text+0x94874): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status I created a tarball http://davidlt.web.cern.ch/davidlt/vault/bugzilla_pr_arm64_ld.tar.xz of 3.1M. It contains logs and minimal binaries required to reproduce this failure (launch ./build.sh). This will generate libcvmfs.a and then attempt to build a small test application. $ tar tf bugzilla_pr_arm64_ld.tar.xz bugzilla_pr_arm64_ld/ bugzilla_pr_arm64_ld/combine_libs bugzilla_pr_arm64_ld/libcurl.a bugzilla_pr_arm64_ld/build.sh bugzilla_pr_arm64_ld/libsqlite3.a bugzilla_pr_arm64_ld/libcvmfs_public_syms.txt bugzilla_pr_arm64_ld/combine_libs.log bugzilla_pr_arm64_ld/libcares.a bugzilla_pr_arm64_ld/link_failures.log bugzilla_pr_arm64_ld/libcvmfs.h bugzilla_pr_arm64_ld/libz.a bugzilla_pr_arm64_ld/libpacparser.a bugzilla_pr_arm64_ld/test_libcvmfs.cc bugzilla_pr_arm64_ld/libcvmfs_only.a
David, thanks for reporting this. I will have a look.
Reproduced. And after a quick investigation I believe the root cause is exactly what Richard Henderson has explained at https://sourceware.org/ml/binutils/2014-07/msg00155.html
AArch64 have counted the got entry in check_relocs for local symbol, while we haven't do any thing during entry allocation, and when doing the final relocation in elfNN_aarch64_final_link_relocate, we only update the relocation value to got entry offset for global symbol. Needs support for local symbol as well. 4837 case BFD_RELOC_AARCH64_LD64_GOT_LO12_NC: 4838 case BFD_RELOC_AARCH64_LD32_GOT_LO12_NC: 4839 case BFD_RELOC_AARCH64_ADR_GOT_PAGE: 4840 case BFD_RELOC_AARCH64_GOT_LD_PREL19: 4841 if (globals->root.sgot == NULL) 4842 BFD_ASSERT (h != NULL); 4843 4844 if (h != NULL) 4845 { 4846 value = aarch64_calculate_got_entry_vma (h, globals, info, value, 4847 output_bfd, 4848 unresolved_reloc_p); 4849 value = _bfd_aarch64_elf_resolve_relocation (bfd_r_type, place, value, 4850 0, weak_undef_p); 4851 } 4852 break
patch for review https://sourceware.org/ml/binutils/2015-04/msg00302.html
Thanks for the bugfix! I think you mentioned a wrong PR in changelog. PR18279 instead of PR18270.
The master branch has been updated by Jiong Wang <jiwang@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b53b1bedbd90044714fc456843cadccce0f208f3 commit b53b1bedbd90044714fc456843cadccce0f208f3 Author: Jiong Wang <jiong.wang@arm.com> Date: Fri Apr 24 23:25:28 2015 +0100 [AArch64] PR18270, fix handling of GOT entry for local symbol 2015-04-24 Jiong. Wang <jiong.wang@arm.com> bfd/ PR ld/18270 * elfnn-aarch64.c (elfNN_aarch64_size_dynamic): Count local symbol for GOT_NORMAL for both sgot/srelgot section. (elfNN_aarch64_final_link_relocate): Relocate against GOT entry address and generate necessary runtime relocation for GOT entry.
The binutils-2_25-branch branch has been updated by Jiong Wang <jiwang@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0381bf126c395b2fe13dfbc98ff82172f82589da commit 0381bf126c395b2fe13dfbc98ff82172f82589da Author: Jiong Wang <jiong.wang@arm.com> Date: Tue May 5 20:58:27 2015 +0100 [AArch64][Backport] PR18270, fix handling of GOT entry for local symbol Applied from master 2015-04-24 Jiong. Wang <jiong.wang@arm.com> bfd/ PR ld/18270 * elfnn-aarch64.c (elfNN_aarch64_size_dynamic): Count local symbol for GOT_NORMAL for both sgot/srelgot section. (elfNN_aarch64_final_link_relocate): Relocate against GOT entry address and generate necessary runtime relocation for GOT entry.
mark as fixed
This patch fixes the errors but it introduces another problem, however. It lacks the _bfd_aarch64_elf_resolve_relocation call and therefore inserts the absolute GOT entry address, while an offset to the GOT entry should be used instead. The missing call has been silently added as a part of another commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=99ad26cb0d4f9152dbe5ed03b74020cc52d84d94;hp=a921b5bd708cc6e8afa3cf33443cda54b4e8cae6 2.25.1 is now broken. The _bfd_aarch64_elf_resolve_relocation call should be backported to the 2.25.1 branch to fix it.