| Summary: | relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, when linking libQtGui.so.4.8.7 | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Thomas Petazzoni <thomas.petazzoni> |
| Component: | ld | Assignee: | Stafford Horne <shorne> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | giulio.benetti, nickc, shorne |
| Priority: | P2 | ||
| Version: | 2.28 | ||
| Target Milestone: | --- | ||
| Host: | Target: | or1k-*-* | |
| Build: | Last reconfirmed: | 2021-03-22 00:00:00 | |
| Bug Depends on: | 27746 | ||
| Bug Blocks: | 28735 | ||
|
Description
Thomas Petazzoni
2017-05-06 13:13:35 UTC
That probably means there are more than 32k GOT entries. There is no R_OR1K_GOT32 relocation, so it looks like or1k doesn't support such big shared libraries. The same issue still exists with binutils 2.28. Steps to reproduce: $ git://git.busybox.net/buildroot $ cd buildroot/ $ git checkout 25902b111a93e562e3c1991f65c03649c88802c4 $ cat > .config <<EOF BR2_or1k=y BR2_BINUTILS_VERSION_2_28_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y BR2_INIT_NONE=y BR2_SYSTEM_BIN_SH_NONE=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_QT=y # BR2_PACKAGE_QT_XML is not set # BR2_TARGET_ROOTFS_TAR is not set EOF $ make olddefconfig $ make This issue still exists with version 2.31.1 when building protobuf on OpenRisc: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 collect2: error: ld returned 1 exit status make[4]: *** [Makefile:2694: libprotobuf-lite.la] Error 1 make[4]: *** Waiting for unfinished jobs.... /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `deregister_tm_clones': crtstuff.c:(.text+0x48): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_deregisterTMCloneTable' /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `register_tm_clones': crtstuff.c:(.text+0xd8): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_registerTMCloneTable' /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x158): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/or1k-buildroot-linux-uclibc/sysroot/lib/libc.so.1 /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: crtstuff.c:(.text+0x1e0): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: in function `frame_dummy': crtstuff.c:(.text+0x278): relocation truncated to fit: R_OR1K_GOT16 against symbol `__register_frame_info@@GLIBC_2.0' defined in .text section in /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: crtstuff.c:(.text+0x2c0): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_Jv_RegisterClasses' /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::CheckedArrayByteSink::CheckedArrayByteSink(char*, unsigned int)': bytestream.cc:(.text+0x3bc): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::CheckedArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20CheckedArrayByteSinkE[_ZTVN6google8protobuf7strings20CheckedArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::GrowingArrayByteSink::GrowingArrayByteSink(unsigned int)': bytestream.cc:(.text+0x668): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::GrowingArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20GrowingArrayByteSinkE[_ZTVN6google8protobuf7strings20GrowingArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::GrowingArrayByteSink::~GrowingArrayByteSink()': bytestream.cc:(.text+0x714): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::GrowingArrayByteSink' defined in .data.rel.ro._ZTVN6google8protobuf7strings20GrowingArrayByteSinkE[_ZTVN6google8protobuf7strings20GrowingArrayByteSinkE] section in google/protobuf/stubs/.libs/bytestream.o /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `google::protobuf::strings::LimitByteSource::LimitByteSource(google::protobuf::strings::ByteSource*, unsigned int)': bytestream.cc:(.text+0xf3c): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for google::protobuf::strings::LimitByteSource' defined in .data.rel.ro._ZTVN6google8protobuf7strings15LimitByteSourceE[_ZTVN6google8protobuf7strings15LimitByteSourceE] section in google/protobuf/stubs/.libs/bytestream.o /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: google/protobuf/stubs/.libs/bytestream.o: in function `__static_initialization_and_destruction_0(int, int)': bytestream.cc:(.text+0x1444): additional relocation overflows omitted from the output /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.31.1 assertion fail elf32-or1k.c:1752 collect2: error: ld returned 1 exit status make[4]: *** [Makefile:2847: libprotobuf.la] Error 1 make[3]: *** [Makefile:1733: all-recursive] Error 1 make[2]: *** [Makefile:1640: all] Error 2 make[1]: *** [package/pkg-generic.mk:274: /home/giuliobenetti/br_reproduce/f800a5f24cb4b23231165ad60c03bf177bad4a9f/output/build/protobuf-3.11.0/.stamp_built] Error 2 make: *** [Makefile:23: _all] Error 2 This issue can be reproduced using the following steps: o reproduce it: # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build 9084cd777aefe0fa8235514c33767d8640ad7a5b Can't still find a workaround. Hi Thomas, I tried to reproduce this problem using the latest development binutils sources. I may have misconfigured the linker, but when I used it, I encountered this error: ld: /home/nickc/work/sources/delme/9084cd777aefe0fa8235514c33767d8640ad7a5b/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-uclibc/5.4.0/crtbeginS.o: addend should be zero for plt relocations Does this seem to be a likely problem, or am I using a bad configuration ? (If the latter, please can you let me know the correct configuration). Cheers Nick Hi Nick, this bug still shows up with binutils 2.36.1 like: /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 collect2: error: ld returned 1 exit status To reproduce it: # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build 6c87be004adf03955c832be72c0c59749f311f71 And I still can't find a workaround. Do you have any idea to fix this? Thank you On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=21464 > > --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> --- > Hi Nick, > > this bug still shows up with binutils 2.36.1 like: > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 > collect2: error: ld returned 1 exit status > > To reproduce it: > # git clone git://git.busybox.net/buildroot > # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build > > - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: > # chmod a+x br-reproduce-build > # ./br-reproduce-build 6c87be004adf03955c832be72c0c59749f311f71 > > And I still can't find a workaround. > > Do you have any idea to fix this? Hello, Sorry I missed the first mail. At first look I don't know how to fix this. I will have a look, I spent some time last year fixing many bugs with the or1k linker code pointed out by glibc testing. Those fixes are all upstream now. I didn't see this one before. I will look at it. For my reference: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elf32-or1k.c;h=65938e51378d2c68b60769ba7d6f5443f18bea5d;hb=HEAD#l2377 2347 static bfd_boolean 2348 or1k_elf_finish_dynamic_symbol (bfd *output_bfd, 2349 struct bfd_link_info *info, 2350 struct elf_link_hash_entry *h, 2351 Elf_Internal_Sym *sym) 2352 { 2353 struct elf_or1k_link_hash_table *htab; 2354 bfd_byte *loc; 2355 2356 htab = or1k_elf_hash_table (info); 2357 if (htab == NULL) 2358 return FALSE; 2359 2360 if (h->plt.offset != (bfd_vma) -1) 2361 { 2362 unsigned int plt0, plt1, plt2; 2363 asection *splt; 2364 asection *sgot; 2365 asection *srela; 2366 bfd_vma plt_base_addr; 2367 bfd_vma plt_addr; 2368 bfd_vma plt_index; 2369 bfd_vma plt_reloc; 2370 bfd_vma got_base_addr; 2371 bfd_vma got_offset; 2372 bfd_vma got_addr; 2373 Elf_Internal_Rela rela; 2374 2375 /* This symbol has an entry in the procedure linkage table. Set 2376 it up. */ 2377 BFD_ASSERT (h->dynindx != -1); My Docs: http://stffrdhrn.github.io/software/toolchain/openrisc/2020/07/21/relocs_tls_impl.html#phase-4---finishing-up-finish_dynamic_symbol--finish_dynamic_sections Notes: https://gist.github.com/stffrdhrn/d59e1d082430a48643b301c13f6f4d24 bfd/elflink.c bfd_elf_gc_common_final_link - bfd_elf_gc_common_finalize_got_offsets - local_got.offsets setup bfd_elf_final_link() - elf_link_input_bfd - or1k_elf_relocate_section - BFD API, P3 main worker writes to sections - travers(elf_link_output_extsym) - called 2 times - or1k_elf_finish_dynamic_symbol - BFD API, P4 for a symbol write to .plt, .got + .got.rela - or1k_elf_finish_dynamic_sections - BFD API, P4 add final things to .plt, etc -Stafford On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>
> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
> com wrote:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> >
> > --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> > Hi Nick,
> >
> > this bug still shows up with binutils 2.36.1 like:
> > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> > /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> > BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> > collect2: error: ld returned 1 exit status
> >
Hello,
I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
latest glibc toolchain versions, and I also did some debugging of LD to try to
get an idea of what is going on.
Reproduced with:
- Just building protobuf on its own, not using buildroot, that was giving me
some exceptions about not being able to find a thread librarty.
Notes
1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
in the latest LD. I maybe have removed it incorrectly with some recent changes? The
issue is not fixed. The R_OR1K_GOT16 relocation limit means OpenRISC fails to
run some PLT entries at run time when there are too many symbols. I am planning
to fix this.
I have two ideas:
1. When we get to big plt entries over the limit will use 2 relocations to
compose the GOT offset
2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
When we go over 32k we have another trampoline, that adds 16k and jumps to
the previous trampoline.
2. The "assertion fail elf32-or1k.c:2377" seems to be something different to me,
and not related to the count of GOT entries, maybe it should be a different bug issue?
3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are failing on is:
Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460, info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
2377 BFD_ASSERT (h->dynindx != -1);
So, it's asserting that the dynindx is defined, in or1k_elf_finish_dynamic_symbol before
we write out the PLT entry.
In the failure cases we see:
h->root.type bfd_link_hash_defweak AND h->forced_local
These failing symbols have been forced_local but we are still trying to write the PLT entry.
That doesn't seem to make much sense.
The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the generic
elflink code:
#0 _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>, h=0x2bcbeb8, force_local=1) at /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
#1 0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8, data=0x7fffffffb2f0) at /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
#2 0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790, func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>, info=info@entry=0x7fffffffb2f0)
I tried to look at other architectures and I see that most do the same assert, so
so would they also fail?
In riscv (a relatively modern implementation) they seem to just detect this case and return FALSE.
I will try to do that and send a patch, but it will be hard to test.
Any suggestion for a test case for this?
-Stafford
Hi Stafford, Il 21/03/2021 04:00, shorne at gmail dot com ha scritto: > https://sourceware.org/bugzilla/show_bug.cgi?id=21464 > > --- Comment #7 from Stafford Horne <shorne at gmail dot com> --- > On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote: >> https://sourceware.org/bugzilla/show_bug.cgi?id=21464 >> >> --- Comment #6 from Stafford Horne <shorne at gmail dot com> --- >> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot >> com wrote: >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464 >>> >>> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> --- >>> Hi Nick, >>> >>> this bug still shows up with binutils 2.36.1 like: >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld: >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377 >>> collect2: error: ld returned 1 exit status >>> > > Hello, > > I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my > latest glibc toolchain versions, and I also did some debugging of LD to try to > get an idea of what is going on. > > Reproduced with: > - Just building protobuf on its own, not using buildroot, that was giving me > some exceptions about not being able to find a thread librarty. > > Notes > > 1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted > in the latest LD. I maybe have removed it incorrectly with some recent > changes? The > issue is not fixed. The R_OR1K_GOT16 relocation limit means OpenRISC fails > to > run some PLT entries at run time when there are too many symbols. I am > planning > to fix this. It seems to be the same bug since it fails on assert(), but maybe I'm wrong. > I have two ideas: > 1. When we get to big plt entries over the limit will use 2 relocations to > compose the GOT offset > 2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k > When we go over 32k we have another trampoline, that adds 16k and jumps > to > the previous trampoline. > > 2. The "assertion fail elf32-or1k.c:2377" seems to be something different to > me, > and not related to the count of GOT entries, maybe it should be a different > bug issue? Yes, it seems since... > 3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are > failing on is: > > Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460, > info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377 > 2377 BFD_ASSERT (h->dynindx != -1); > > So, it's asserting that the dynindx is defined, in > or1k_elf_finish_dynamic_symbol before > we write out the PLT entry. > > In the failure cases we see: > > h->root.type bfd_link_hash_defweak AND h->forced_local > > These failing symbols have been forced_local but we are still trying to > write the PLT entry. > That doesn't seem to make much sense. > > The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the > generic > elflink code: > > #0 _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>, > h=0x2bcbeb8, force_local=1) at > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756 > #1 0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8, > data=0x7fffffffb2f0) at > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483 > #2 0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790, > func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>, > info=info@entry=0x7fffffffb2f0) > > I tried to look at other architectures and I see that most do the same > assert, so > so would they also fail? > > In riscv (a relatively modern implementation) they seem to just detect this > case and return FALSE. > I will try to do that and send a patch, but it will be hard to test. I've tried to imitate what riscv does: ''' diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c index 65938e5137..74cff4bf01 100644 --- a/bfd/elf32-or1k.c +++ b/bfd/elf32-or1k.c @@ -2372,15 +2372,22 @@ or1k_elf_finish_dynamic_symbol (bfd *output_bfd, bfd_vma got_addr; Elf_Internal_Rela rela; - /* This symbol has an entry in the procedure linkage table. Set - it up. */ - BFD_ASSERT (h->dynindx != -1); - splt = htab->root.splt; sgot = htab->root.sgotplt; srela = htab->root.srelplt; BFD_ASSERT (splt != NULL && sgot != NULL && srela != NULL); + /* This symbol has an entry in the procedure linkage table. Set + it up. */ + if ((h->dynindx == -1 + && !((h->forced_local || bfd_link_executable (info)) + && h->def_regular + && h->type == STT_GNU_IFUNC)) + || splt == NULL + || sgot == NULL + || srela == NULL) + return FALSE; + plt_base_addr = splt->output_section->vma + splt->output_offset; got_base_addr = sgot->output_section->vma + sgot->output_offset; -- ''' but it still fails and without emitting anything, only: collect2: error: ld returned 1 exit status > Any suggestion for a test case for this? > > -Stafford > Another package that has the same problem is libtheora I don't know how to help you more. Tell me if you need something else Kind regards On Sun, Mar 21, 2021 at 06:09:09PM +0000, giulio.benetti at micronovasrl dot com wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>
> --- Comment #8 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> Hi Stafford,
>
> Il 21/03/2021 04:00, shorne at gmail dot com ha scritto:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> >
> > --- Comment #7 from Stafford Horne <shorne at gmail dot com> ---
> > On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> >>
> >> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
> >> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
> >> com wrote:
> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
> >>>
> >>> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
> >>> Hi Nick,
> >>>
> >>> this bug still shows up with binutils 2.36.1 like:
> >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> >>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
> >>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
> >>> collect2: error: ld returned 1 exit status
> >>>
> >
> > Hello,
> >
> > I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
> > latest glibc toolchain versions, and I also did some debugging of LD to try to
> > get an idea of what is going on.
> >
> > Reproduced with:
> > - Just building protobuf on its own, not using buildroot, that was giving me
> > some exceptions about not being able to find a thread librarty.
> >
> > Notes
> >
> > 1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
> > in the latest LD. I maybe have removed it incorrectly with some recent
> > changes? The
> > issue is not fixed. The R_OR1K_GOT16 relocation limit means OpenRISC fails
> > to
> > run some PLT entries at run time when there are too many symbols. I am
> > planning
> > to fix this.
>
> It seems to be the same bug since it fails on assert(), but maybe I'm wrong.
>
> > I have two ideas:
> > 1. When we get to big plt entries over the limit will use 2 relocations to
> > compose the GOT offset
> > 2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
> > When we go over 32k we have another trampoline, that adds 16k and jumps
> > to
> > the previous trampoline.
> >
> > 2. The "assertion fail elf32-or1k.c:2377" seems to be something different to
> > me,
> > and not related to the count of GOT entries, maybe it should be a different
> > bug issue?
>
> Yes, it seems since...
>
> > 3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are
> > failing on is:
> >
> > Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460,
> > info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at
> > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
> > 2377 BFD_ASSERT (h->dynindx != -1);
> >
> > So, it's asserting that the dynindx is defined, in
> > or1k_elf_finish_dynamic_symbol before
> > we write out the PLT entry.
> >
> > In the failure cases we see:
> >
> > h->root.type bfd_link_hash_defweak AND h->forced_local
> >
> > These failing symbols have been forced_local but we are still trying to
> > write the PLT entry.
> > That doesn't seem to make much sense.
> >
> > The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the
> > generic
> > elflink code:
> >
> > #0 _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>,
> > h=0x2bcbeb8, force_local=1) at
> > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
> > #1 0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8,
> > data=0x7fffffffb2f0) at
> > /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
> > #2 0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790,
> > func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>,
> > info=info@entry=0x7fffffffb2f0)
> >
> > I tried to look at other architectures and I see that most do the same
> > assert, so
> > so would they also fail?
> >
> > In riscv (a relatively modern implementation) they seem to just detect this
> > case and return FALSE.
> > I will try to do that and send a patch, but it will be hard to test.
>
> I've tried to imitate what riscv does:
> '''
> diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
> index 65938e5137..74cff4bf01 100644
> --- a/bfd/elf32-or1k.c
> +++ b/bfd/elf32-or1k.c
> @@ -2372,15 +2372,22 @@ or1k_elf_finish_dynamic_symbol (bfd *output_bfd,
> bfd_vma got_addr;
> Elf_Internal_Rela rela;
>
> - /* This symbol has an entry in the procedure linkage table. Set
> - it up. */
> - BFD_ASSERT (h->dynindx != -1);
> -
> splt = htab->root.splt;
> sgot = htab->root.sgotplt;
> srela = htab->root.srelplt;
> BFD_ASSERT (splt != NULL && sgot != NULL && srela != NULL);
>
> + /* This symbol has an entry in the procedure linkage table. Set
> + it up. */
> + if ((h->dynindx == -1
> + && !((h->forced_local || bfd_link_executable (info))
> + && h->def_regular
> + && h->type == STT_GNU_IFUNC))
> + || splt == NULL
> + || sgot == NULL
> + || srela == NULL)
> + return FALSE;
> +
> plt_base_addr = splt->output_section->vma + splt->output_offset;
> got_base_addr = sgot->output_section->vma + sgot->output_offset;
>
> --
> '''
>
> but it still fails and without emitting anything, only:
> collect2: error: ld returned 1 exit status
>
> > Any suggestion for a test case for this?
> >
I did some more investigation about why we are actually calling the dynamic
finishup code for these symbols.
I found some other code that might help...
diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
index 38406eda3d6..f1cfed230a1 100644
--- a/bfd/elf32-or1k.c
+++ b/bfd/elf32-or1k.c
@@ -2566,11 +2566,10 @@ or1k_elf_adjust_dynamic_symbol (struct bfd_link_info
*info,
if (h->type == STT_FUNC
|| h->needs_plt)
{
- if (! bfd_link_pic (info)
- && !h->def_dynamic
- && !h->ref_dynamic
- && h->root.type != bfd_link_hash_undefweak
- && h->root.type != bfd_link_hash_undefined)
+ if (h->plt.refcount <= 0
+ || (SYMBOL_CALLS_LOCAL (info, h)
+ || (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
+ && h->root.type == bfd_link_hash_undefweak)))
{
/* This case can occur if we saw a PLT reloc in an input
file, but the symbol was never referred to by a dynamic
--
With this patch we skip the PLT calls once we determine they have been "forced
local". It seems to work.
-Stafford
Il 21/03/2021 22:29, shorne at gmail dot com ha scritto:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>
> --- Comment #9 from Stafford Horne <shorne at gmail dot com> ---
> On Sun, Mar 21, 2021 at 06:09:09PM +0000, giulio.benetti at micronovasrl dot
> com wrote:
>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>
>> --- Comment #8 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
>> Hi Stafford,
>>
>> Il 21/03/2021 04:00, shorne at gmail dot com ha scritto:
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>
>>> --- Comment #7 from Stafford Horne <shorne at gmail dot com> ---
>>> On Wed, Mar 17, 2021 at 10:10:13PM +0000, shorne at gmail dot com wrote:
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>>
>>>> --- Comment #6 from Stafford Horne <shorne at gmail dot com> ---
>>>> On Wed, Mar 17, 2021 at 09:31:59PM +0000, giulio.benetti at micronovasrl dot
>>>> com wrote:
>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=21464
>>>>>
>>>>> --- Comment #5 from Giulio Benetti <giulio.benetti at micronovasrl dot com> ---
>>>>> Hi Nick,
>>>>>
>>>>> this bug still shows up with binutils 2.36.1 like:
>>>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>>>> /home/giuliobenetti/git/upstream/or1k-binutils-2.36.1/host/lib/gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/bin/ld:
>>>>> BFD (GNU Binutils) 2.36.1 assertion fail elf32-or1k.c:2377
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>
>>> Hello,
>>>
>>> I was able to reproduce the "assertion fail elf32-or1k.c:2377" issue with my
>>> latest glibc toolchain versions, and I also did some debugging of LD to try to
>>> get an idea of what is going on.
>>>
>>> Reproduced with:
>>> - Just building protobuf on its own, not using buildroot, that was giving me
>>> some exceptions about not being able to find a thread librarty.
>>>
>>> Notes
>>>
>>> 1. The "relocation truncated to fit: R_OR1K_GOT16" error seems not be outputted
>>> in the latest LD. I maybe have removed it incorrectly with some recent
>>> changes? The
>>> issue is not fixed. The R_OR1K_GOT16 relocation limit means OpenRISC fails
>>> to
>>> run some PLT entries at run time when there are too many symbols. I am
>>> planning
>>> to fix this.
>>
>> It seems to be the same bug since it fails on assert(), but maybe I'm wrong.
>>
>>> I have two ideas:
>>> 1. When we get to big plt entries over the limit will use 2 relocations to
>>> compose the GOT offset
>>> 2. Use an extra PLT trampoline entry to add the extra offset i.e. 16k
>>> When we go over 32k we have another trampoline, that adds 16k and jumps
>>> to
>>> the previous trampoline.
>>>
>>> 2. The "assertion fail elf32-or1k.c:2377" seems to be something different to
>>> me,
>>> and not related to the count of GOT entries, maybe it should be a different
>>> bug issue?
>>
>> Yes, it seems since...
>>
>>> 3. When debugging the "assertion fail elf32-or1k.c:2377" I see, the line we are
>>> failing on is:
>>>
>>> Breakpoint 1, or1k_elf_finish_dynamic_symbol (output_bfd=0x568460,
>>> info=0x543320 <link_info>, h=0x81c0f8, sym=0x7fffffffb260) at
>>> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elf32-or1k.c:2377
>>> 2377 BFD_ASSERT (h->dynindx != -1);
>>>
>>> So, it's asserting that the dynindx is defined, in
>>> or1k_elf_finish_dynamic_symbol before
>>> we write out the PLT entry.
>>>
>>> In the failure cases we see:
>>>
>>> h->root.type bfd_link_hash_defweak AND h->forced_local
>>>
>>> These failing symbols have been forced_local but we are still trying to
>>> write the PLT entry.
>>> That doesn't seem to make much sense.
>>>
>>> The forced_local has been set in _bfd_elf_link_hash_hide_symbol(), the
>>> generic
>>> elflink code:
>>>
>>> #0 _bfd_elf_link_hash_hide_symbol (info=0x543320 <link_info>,
>>> h=0x2bcbeb8, force_local=1) at
>>> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:7756
>>> #1 0x000000000045e61e in _bfd_elf_link_assign_sym_version (h=0x2bcbeb8,
>>> data=0x7fffffffb2f0) at
>>> /home/shorne/work/gnu-toolchain/binutils-gdb/bfd/elflink.c:2483
>>> #2 0x000000000043055d in bfd_link_hash_traverse (htab=0x56a790,
>>> func=func@entry=0x45e33d <_bfd_elf_link_assign_sym_version>,
>>> info=info@entry=0x7fffffffb2f0)
>>>
>>> I tried to look at other architectures and I see that most do the same
>>> assert, so
>>> so would they also fail?
>>>
>>> In riscv (a relatively modern implementation) they seem to just detect this
>>> case and return FALSE.
>>> I will try to do that and send a patch, but it will be hard to test.
>>
>> I've tried to imitate what riscv does:
>> '''
>> diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
>> index 65938e5137..74cff4bf01 100644
>> --- a/bfd/elf32-or1k.c
>> +++ b/bfd/elf32-or1k.c
>> @@ -2372,15 +2372,22 @@ or1k_elf_finish_dynamic_symbol (bfd *output_bfd,
>> bfd_vma got_addr;
>> Elf_Internal_Rela rela;
>>
>> - /* This symbol has an entry in the procedure linkage table. Set
>> - it up. */
>> - BFD_ASSERT (h->dynindx != -1);
>> -
>> splt = htab->root.splt;
>> sgot = htab->root.sgotplt;
>> srela = htab->root.srelplt;
>> BFD_ASSERT (splt != NULL && sgot != NULL && srela != NULL);
>>
>> + /* This symbol has an entry in the procedure linkage table. Set
>> + it up. */
>> + if ((h->dynindx == -1
>> + && !((h->forced_local || bfd_link_executable (info))
>> + && h->def_regular
>> + && h->type == STT_GNU_IFUNC))
>> + || splt == NULL
>> + || sgot == NULL
>> + || srela == NULL)
>> + return FALSE;
>> +
>> plt_base_addr = splt->output_section->vma + splt->output_offset;
>> got_base_addr = sgot->output_section->vma + sgot->output_offset;
>>
>> --
>> '''
>>
>> but it still fails and without emitting anything, only:
>> collect2: error: ld returned 1 exit status
>>
>>> Any suggestion for a test case for this?
>>>
>
> I did some more investigation about why we are actually calling the dynamic
> finishup code for these symbols.
>
> I found some other code that might help...
>
> diff --git a/bfd/elf32-or1k.c b/bfd/elf32-or1k.c
> index 38406eda3d6..f1cfed230a1 100644
> --- a/bfd/elf32-or1k.c
> +++ b/bfd/elf32-or1k.c
> @@ -2566,11 +2566,10 @@ or1k_elf_adjust_dynamic_symbol (struct bfd_link_info
> *info,
> if (h->type == STT_FUNC
> || h->needs_plt)
> {
> - if (! bfd_link_pic (info)
> - && !h->def_dynamic
> - && !h->ref_dynamic
> - && h->root.type != bfd_link_hash_undefweak
> - && h->root.type != bfd_link_hash_undefined)
> + if (h->plt.refcount <= 0
> + || (SYMBOL_CALLS_LOCAL (info, h)
> + || (ELF_ST_VISIBILITY (h->other) != STV_DEFAULT
> + && h->root.type == bfd_link_hash_undefweak)))
> {
> /* This case can occur if we saw a PLT reloc in an input
> file, but the symbol was never referred to by a dynamic
>
> --
>
> With this patch we skip the PLT calls once we determine they have been "forced
> local". It seems to work.
>
> -Stafford
>
Hi Stafford,
thank you for providing such fix, it works with binutils:
- 2.32
- 2.34
- 2.35.2
- 2.36.1
while building these packages:
- protobuf
- libtheora
- zeromq
that were previously failing to link.
Thanks a lot!
Best regards
Giulio Benetti
Hi Stafford, I've given a try to build libgeos and it still doesn't link, but then we're facing 2 different bugs and I've mixed them up. With libgeos it's true that linker hangs on assert() but before it emits "relocation truncated to fit: R_OR1K_GOT16 against symbol" So what you've propose fixes another bug that I'm going to submit. So I ask you if you can fix the current bug: relocation truncated to fit: R_OR1K_GOT16 against symbol Thank you! Stafford, this is the bug you've fixed: https://sourceware.org/bugzilla/show_bug.cgi?id=27624 So this is still pending. Hi Giulio, What issue are you seeing for geos, I am wondering if it is also something different. I tried to build it and I see again different issues, not the "relocation truncated to fit: R_OR1K_GOT16 against symbol" issue. See below for what I see. Note, I am not sure I am building this correctly and maybe this is an issue with how cmake is passing link arguments to ld. # Cross compile setting CXX/CC compilers CXX=or1k-smh-linux-gnu-g++ CC=or1k-smh-linux-gnu-gcc cmake ../geos/ # Need to suppress this warning make CXX_FLAGS="$CXX_FLAGS -Wno-error=nonnull" # then I see: [ 34%] Linking CXX shared library lib/libgeos.so /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZN4geos5index7strtree15AbstractSTRtreeC2Ej /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZN4geos5index12SpatialIndexC2Ev /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZTVN4geos5index7strtree7STRtreeE /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZTVN4geos5index7strtree7STRtreeE /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZTVN4geos5index7strtree7STRtreeE ... /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZSt4moveIRPN4geos5index7strtree9BoundableEEONSt16remove_referenceIT_E4typeEOS7_ /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4 /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol __dso_handle /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol __dso_handle /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4 /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4 /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation against dynamic symbol __cxa_atexit@@GLIBC_2.33 /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/geos.dir/build.make:5370: lib/libgeos.so.3.10.0dev] Error 1 make[1]: *** [CMakeFiles/Makefile2:1173: CMakeFiles/geos.dir/all] Error 2 readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep __dso_handle 000059a4 0006aa23 R_OR1K_AHI16 00000000 __dso_handle + 0 000059a8 0006aa04 R_OR1K_LO_16_IN_I 00000000 __dso_handle + 0 readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep __cxa_atexit 000059bc 0006ac06 R_OR1K_INSN_REL_2 00000000 __cxa_atexit + 0 Il 23/03/2021 00:36, shorne at sourceware dot org ha scritto: > https://sourceware.org/bugzilla/show_bug.cgi?id=21464 > > Stafford Horne <shorne at sourceware dot org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Ever confirmed|0 |1 > Assignee|unassigned at sourceware dot org |shorne at sourceware dot org > Last reconfirmed| |2021-03-22 > Status|UNCONFIRMED |ASSIGNED > > --- Comment #13 from Stafford Horne <shorne at sourceware dot org> --- > Hi Giulio, > > What issue are you seeing for geos, I am wondering if it is also something > different. I tried to build it and I see again different issues, not the > "relocation truncated to fit: R_OR1K_GOT16 against symbol" issue. > > See below for what I see. > > Note, I am not sure I am building this correctly and maybe this is an issue > with how cmake is passing link arguments to ld. > > # Cross compile setting CXX/CC compilers > CXX=or1k-smh-linux-gnu-g++ CC=or1k-smh-linux-gnu-gcc cmake ../geos/ > > # Need to suppress this warning > make CXX_FLAGS="$CXX_FLAGS -Wno-error=nonnull" > > # then I see: > > [ 34%] Linking CXX shared library lib/libgeos.so > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol _ZN4geos5index7strtree15AbstractSTRtreeC2Ej > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol _ZN4geos5index12SpatialIndexC2Ev > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol _ZTVN4geos5index7strtree7STRtreeE > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol _ZTVN4geos5index7strtree7STRtreeE > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol _ZTVN4geos5index7strtree7STRtreeE > ... > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZSt4moveIRPN4geos5index7strtree9BoundableEEONSt16remove_referenceIT_E4typeEOS7_ > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEplEi > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol > _ZNK9__gnu_cxx17__normal_iteratorIPPN4geos5index7strtree9BoundableESt6vectorIS5_SaIS5_EEEdeEv > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol __dso_handle > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol __dso_handle > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation against > symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol __cxa_atexit@@GLIBC_2.33 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../../../../or1k-smh-linux-gnu/bin/ld: > final link failed: bad value > collect2: error: ld returned 1 exit status This link failure should be due to lacking of -fPIC > make[2]: *** [CMakeFiles/geos.dir/build.make:5370: lib/libgeos.so.3.10.0dev] > Error 1 > make[1]: *** [CMakeFiles/Makefile2:1173: CMakeFiles/geos.dir/all] Error 2 > > > > readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep > __dso_handle > 000059a4 0006aa23 R_OR1K_AHI16 00000000 __dso_handle + 0 > 000059a8 0006aa04 R_OR1K_LO_16_IN_I 00000000 __dso_handle + 0 > > > readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep > __cxa_atexit > 000059bc 0006ac06 R_OR1K_INSN_REL_2 00000000 __cxa_atexit + 0 > Hi Stafford, have you tried to reproduce it with Buildroot with this: ''' # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build 3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c ''' ? Other commands are needed to avoid rebuilding everything again and again. so after the ones above: # cd 9084cd777aefe0fa8235514c33767d8640ad7a5b # cd output # make V=1 libgeos This ^^^^ is to rebuilding even if it failed and passing V=1 evrything is verbose, so you can get exactly C/CXX/LDFLAGS. You can also find the sources of binutils under output/build/host-binutilsXX.X/ so there you can modify and then rebuild binutils with: # cd output # make host-binutils This ^^^ should rebuild modified sources and re-install the binaries under output/host/usr/bin that is were buildroot takes binutils binaries. I give you the exact FLAGS passed by Buildroot anyway: CXX_FLAGS = -DNDEBUG -fPIC -ffp-contract=off -std=c++11 LDFLAGS = -fPIC -DNDEBUG Hope this helps Best regards (In reply to Stafford Horne from comment #13) > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../.. > /../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation > against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../.. > /../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: non-pic relocation > against symbol _ZNSt8ios_base4InitD1Ev@@GLIBCXX_3.4 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../.. > /../../or1k-smh-linux-gnu/bin/ld: > CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o: pc-relative relocation > against dynamic symbol __cxa_atexit@@GLIBC_2.33 > /home/shorne/work/gnu-toolchain/local/lib/gcc/or1k-smh-linux-gnu/11.0.0/../.. > /../../or1k-smh-linux-gnu/bin/ld: final link failed: bad value > collect2: error: ld returned 1 exit status > make[2]: *** [CMakeFiles/geos.dir/build.make:5370: lib/libgeos.so.3.10.0dev] > Error 1 > make[1]: *** [CMakeFiles/Makefile2:1173: CMakeFiles/geos.dir/all] Error 2 > > > > readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep > __dso_handle > 000059a4 0006aa23 R_OR1K_AHI16 00000000 __dso_handle + 0 > 000059a8 0006aa04 R_OR1K_LO_16_IN_I 00000000 __dso_handle + 0 > > > readelf -r CMakeFiles/geos.dir/src/index/strtree/STRtree.cpp.o | grep > __cxa_atexit > 000059bc 0006ac06 R_OR1K_INSN_REL_2 00000000 __cxa_atexit + 0 OK, these errors are bogus. They looked strange to me, the issue here was that I changed CXX_FLAGS mid build and it caused the new files to be created without -fPIC, so the final link created all these crazy issues. Rebuilding now with the correct CXX_FLAGS throughout and I see, everything builds fine. What error are you seeing? Am I using the right libgeos? < shorne@lianli ~/work/gnu-toolchain/geos > git remote -v origin https://git.osgeo.org/gitea/geos/geos.git (fetch) origin https://git.osgeo.org/gitea/geos/geos.git (push) < shorne@lianli ~/work/gnu-toolchain/build-geos > make [ 0%] Built target ryu [ 57%] Built target geos [ 58%] Built target geos_c [ 92%] Built target test_geos_unit [ 93%] Built target tinyxml2 [ 93%] Built target test_xmltester [ 94%] Built target test_simplewkttester [ 95%] Built target test_big_sweep_line_speed [ 95%] Built target perf_class_sizes [ 95%] Built target perf_unary [ 95%] Built target perf_intersection [ 95%] Built target perf_geospreparedcontains [ 96%] Built target perf_memleak_mp_prep [ 97%] Built target perf_unaryunion_segments [ 97%] Built target perf_voronoi [ 98%] Built target perf_interiorpoint_area [ 98%] Built target perf_iterated_buffer [ 98%] Built target perf_rectangle_intersects [ 99%] Built target geosop [100%] Built target astyle (In reply to Giulio Benetti from comment #14) > Il 23/03/2021 00:36, shorne at sourceware dot org ha scritto: > > https://sourceware.org/bugzilla/show_bug.cgi?id=21464 > > Hi Stafford, > > have you tried to reproduce it with Buildroot with this: > ''' > # git clone git://git.busybox.net/buildroot > # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build > > - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: > # chmod a+x br-reproduce-build > # ./br-reproduce-build 3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c > ''' > ? > > Other commands are needed to avoid rebuilding everything again and again. > > so after the ones above: > # cd 9084cd777aefe0fa8235514c33767d8640ad7a5b > # cd output > # make V=1 libgeos > This ^^^^ is to rebuilding even if it failed and passing V=1 evrything > is verbose, so you can get exactly C/CXX/LDFLAGS. > You can also find the sources of binutils under > output/build/host-binutilsXX.X/ so there you can modify and then rebuild > binutils with: > # cd output > # make host-binutils > This ^^^ should rebuild modified sources and re-install the binaries > under output/host/usr/bin that is were buildroot takes binutils binaries. > > I give you the exact FLAGS passed by Buildroot anyway: > CXX_FLAGS = -DNDEBUG -fPIC -ffp-contract=off -std=c++11 > LDFLAGS = -fPIC -DNDEBUG > > Hope this helps > > Best regards Hello, I tried to use the br-reproduce-build command before but it was not working. Let me try again with you extra steps. Thanks. And other useful commands: To rebuild libgeos only from scratch: # make V=1 libgeos-dirclean libgeos also if you want to reissue make again only: # make V=1 libgeos-rebuild Both inside output folder I confirm, when building with libgeos as you described I also see the familiar R_OR1K_GOT16 truncation issue. I did some investigation, some points - In an earlier comment I mentioned the runtime PLT overflow, this is not related to this R_OR1K_GOT16 relocation, sorry my mistake. When creating the PLT in or1k_elf_finish_dynamic_symbol the plt_reloc address may have a 16-bit overflow in the l.ori instruction which is not checked. Similar but a different issue. Thats a different bug that I should raise. - This issue is an overflow in the 16-bit immediate in the l.lwz load instruction generated for R_OR1K_GOT16 by GCC. So the fix has to start with GCC. I will need to have a bit further look on how to handle this. For the record some of the errors Errors: linux-uclibc/9.3.0/crtbeginS.o: in function `__do_global_dtors_aux': crtstuff.c:(.text+0x118): relocation truncated to fit: R_OR1K_GOT16 against symbol `__cxa_finalize' defined in .text section in /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/or1k-buildroot-linux-uclibc/sysroot/lib/libc.so. 1 crtstuff.c:(.text+0x140): relocation truncated to fit: R_OR1K_GOT16 against symbol `__deregister_frame_info@@GLIBC_2.0' defined in .text section in /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/opt/ext-toolchain/bin/../lib /gcc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot- linux-uclibc/9.3.0/crtbeginS.o: in function `frame_dummy': crtstuff.c:(.text+0x1a0): relocation truncated to fit: R_OR1K_GOT16 against symbol `__register_frame_info@@GLIBC_2.0' defined in .text section in /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/host/opt/ext-toolchain/bin/../lib/g cc/or1k-buildroot-linux-uclibc/9.3.0/../../../../or1k-buildroot-linux-uclibc/lib/libgcc_s.so CMakeFiles/geos.dir/src/algorithm/BoundaryNodeRule.cpp.o: in function `geos::algorithm::BoundaryNodeRule::~BoundaryNodeRule()': BoundaryNodeRule.cpp:(.text._ZN4geos9algorithm16BoundaryNodeRuleD2Ev[_ZN4geos9algorithm16BoundaryNodeRuleD5Ev]+0x24): relocation truncated to fit: R_OR1K_GOT16 against symbol `vtable for geos::algorithm::BoundaryNodeRule' defined in .data.rel.ro._ZTVN4geos 9algorithm16BoundaryNodeRuleE[_ZTVN4geos9algorithm16BoundaryNodeRuleE] section in CMakeFiles/geos.dir/src/algorithm/BoundaryNode Rule.cpp.o CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o: in function `geos::algorithm::CGAlgorithmsDD::orientationIndex(double, d ouble, double, double, double, double)': CGAlgorithmsDD.cpp:(.text+0x308): relocation truncated to fit: R_OR1K_GOT16 against symbol `geos::util::IllegalArgumentException ::~IllegalArgumentException()' defined in .text._ZN4geos4util24IllegalArgumentExceptionD2Ev[_ZN4geos4util24IllegalArgumentExcept ionD5Ev] section in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o CGAlgorithmsDD.cpp:(.text+0x310): relocation truncated to fit: R_OR1K_GOT16 against symbol `typeinfo for geos::util::IllegalArgu mentException' defined in .data.rel.ro._ZTIN4geos4util24IllegalArgumentExceptionE[_ZTIN4geos4util24IllegalArgumentExceptionE] se ction in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o: in function `geos::algorithm::CGAlgorithmsDD::signOfDet2x2(double, doubl e, double, double)': CGAlgorithmsDD.cpp:(.text+0xa34): relocation truncated to fit: R_OR1K_GOT16 against symbol `geos::util::IllegalArgumentException ::~IllegalArgumentException()' defined in .text._ZN4geos4util24IllegalArgumentExceptionD2Ev[_ZN4geos4util24IllegalArgumentExcept ionD5Ev] section in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o CGAlgorithmsDD.cpp:(.text+0xa3c): relocation truncated to fit: R_OR1K_GOT16 against symbol `typeinfo for geos::util::IllegalArgu mentException' defined in .data.rel.ro._ZTIN4geos4util24IllegalArgumentExceptionE[_ZTIN4geos4util24IllegalArgumentExceptionE] se ction in CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o CMakeFiles/geos.dir/src/algorithm/CGAlgorithmsDD.cpp.o: in function `geos::util::GEOSException::GEOSException(std::__cxx11::basi c_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, s td::allocator<char> > const&)': CGAlgorithmsDD.cpp:(.text._ZN4geos4util13GEOSExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_[_ZN4geos4util 13GEOSExceptionC5ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_]+0xc0): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status make[4]: *** [CMakeFiles/geos.dir/build.make:5369: lib/libgeos.so.3.9.0] Error 1 make[3]: *** [CMakeFiles/Makefile2:359: CMakeFiles/geos.dir/all] Error 2 make[2]: *** [Makefile:172: all] Error 2 make[1]: *** [package/pkg-generic.mk:250: /home/shorne/work/openrisc/3eb9f9d0f6d8274b2d19753c006bd83f7d536e3c/output/build/libge os-3.9.0/.stamp_built] Error 2 make: *** [Makefile:23: _all] Error 2 Ah, so 2 different bugs. When you have some patch to test I can do it. Please tag me in some way on gcc bugzilla when you submit the bug. Thank you! Sure, I will open an issue in GCC there for the R_OR1K_GOT16 truncation issue. I had a look at other architectures they have the ability to pass an argument -mcmodel=large or -mxgot to generate code that will handle large binary sizes. I will have to implement something that does something similar in GCC and then add code to handle the new relocations in the assembler and linker/bfd. The or1k-large-fixes branch has been updated by Stafford Horne <shorne@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b3e14c90283c5d234884d0ebe8510bc3c9bc687 commit 0b3e14c90283c5d234884d0ebe8510bc3c9bc687 Author: Stafford Horne <shorne@gmail.com> Date: Thu May 6 20:51:24 2021 +0900 or1k: Implement relocation R_OR1K_GOT_AHI16 for gotha() The gotha() relocation mnemonic will be outputted by OpenRISC GCC when using the -mcmodel=large option. This relocation is used along with got() to generate 32-bit GOT offsets. This increases the previous GOT offset limit from the previous 16-bit (64K) limit. This is needed on large binaries where the GOT grows larger than 64k. bfd/ChangeLog: PR 21464 * bfd-in2.h: Add BFD_RELOC_OR1K_GOT_AHI16 relocation. * elf32-or1k.c (or1k_elf_howto_table, or1k_reloc_map): Likewise. (or1k_final_link_relocate, or1k_elf_relocate_section, or1k_elf_check_relocs): Likewise. * libbfd.h (bfd_reloc_code_real_names): Likewise. * reloc.c: Likewise. cpu/ChangeLog: PR 21464 * or1k.opc (or1k_imm16_relocs, parse_reloc): Define parse logic for gotha() relocation. include/ChangeLog: PR 21464 * elf/or1k.h (elf_or1k_reloc_type): Define R_OR1K_GOT_AHI16 number. opcodes/ChangeLog: PR 21464 * or1k-asm.c: Regenerate. gas/ChangeLog: PR 21464 * testsuite/gas/or1k/reloc-1.s: Add test for new relocation. * testsuite/gas/or1k/reloc-1.d: Add test result for new relocation. Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> fixup reloc, add tests The or1k-large-fixes branch has been updated by Stafford Horne <shorne@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6 commit 3c3de29b048bca6b4aa4235c647b9328e71801b6 Author: Stafford Horne <shorne@gmail.com> Date: Thu May 6 20:51:25 2021 +0900 or1k: Avoid R_OR1K_GOT16 overflow failures in presence of R_OR1K_GOT_AHI16 Now that we support R_OR1K_GOT_AHI16 we can relax the R_OR1K_GOT16 overflow validation check if the section has R_OR1K_GOT_AHI16. We cannot simple disable R_OR1K_GOT16 overflow validation as there will still be binaries that will have only R_OR1K_GOT16. The R_OR1K_GOT_AHI16 relocation will only be added by GCC when building with the option -mcmodel=large. This assumes that R_OR1K_GOT_AHI16 will come before R_OR1K_GOT16, which is the code pattern that will be emitted by GCC. bfd/ChangeLog: PR 21464 * elf32-or1k.c (or1k_elf_relocate_section): Relax R_OR1K_GOT16 overflow check if we have R_OR1K_GOT_AHI16 followed by R_OR1K_GOT16. The master branch has been updated by Stafford Horne <shorne@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0b3e14c90283c5d234884d0ebe8510bc3c9bc687 commit 0b3e14c90283c5d234884d0ebe8510bc3c9bc687 Author: Stafford Horne <shorne@gmail.com> Date: Thu May 6 20:51:24 2021 +0900 or1k: Implement relocation R_OR1K_GOT_AHI16 for gotha() The gotha() relocation mnemonic will be outputted by OpenRISC GCC when using the -mcmodel=large option. This relocation is used along with got() to generate 32-bit GOT offsets. This increases the previous GOT offset limit from the previous 16-bit (64K) limit. This is needed on large binaries where the GOT grows larger than 64k. bfd/ChangeLog: PR 21464 * bfd-in2.h: Add BFD_RELOC_OR1K_GOT_AHI16 relocation. * elf32-or1k.c (or1k_elf_howto_table, or1k_reloc_map): Likewise. (or1k_final_link_relocate, or1k_elf_relocate_section, or1k_elf_check_relocs): Likewise. * libbfd.h (bfd_reloc_code_real_names): Likewise. * reloc.c: Likewise. cpu/ChangeLog: PR 21464 * or1k.opc (or1k_imm16_relocs, parse_reloc): Define parse logic for gotha() relocation. include/ChangeLog: PR 21464 * elf/or1k.h (elf_or1k_reloc_type): Define R_OR1K_GOT_AHI16 number. opcodes/ChangeLog: PR 21464 * or1k-asm.c: Regenerate. gas/ChangeLog: PR 21464 * testsuite/gas/or1k/reloc-1.s: Add test for new relocation. * testsuite/gas/or1k/reloc-1.d: Add test result for new relocation. Cc: Giulio Benetti <giulio.benetti@benettiengineering.com> fixup reloc, add tests The master branch has been updated by Stafford Horne <shorne@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=3c3de29b048bca6b4aa4235c647b9328e71801b6 commit 3c3de29b048bca6b4aa4235c647b9328e71801b6 Author: Stafford Horne <shorne@gmail.com> Date: Thu May 6 20:51:25 2021 +0900 or1k: Avoid R_OR1K_GOT16 overflow failures in presence of R_OR1K_GOT_AHI16 Now that we support R_OR1K_GOT_AHI16 we can relax the R_OR1K_GOT16 overflow validation check if the section has R_OR1K_GOT_AHI16. We cannot simple disable R_OR1K_GOT16 overflow validation as there will still be binaries that will have only R_OR1K_GOT16. The R_OR1K_GOT_AHI16 relocation will only be added by GCC when building with the option -mcmodel=large. This assumes that R_OR1K_GOT_AHI16 will come before R_OR1K_GOT16, which is the code pattern that will be emitted by GCC. bfd/ChangeLog: PR 21464 * elf32-or1k.c (or1k_elf_relocate_section): Relax R_OR1K_GOT16 overflow check if we have R_OR1K_GOT_AHI16 followed by R_OR1K_GOT16. The latest commit should fix this. The master branch has been updated by Stafford Horne <shorne@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c7c6e55b60b072cdcc5c3fc27164b890a0f34520 commit c7c6e55b60b072cdcc5c3fc27164b890a0f34520 Author: Stafford Horne <shorne@gmail.com> Date: Wed Feb 2 20:11:56 2022 +0900 or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto Previously when fixing PR 21464 we masked out upper bits of the relocation value in order to avoid overflow complaints when acceptable. It turns out this does not work when the relocation value ends up being signed. To fix this this patch introduces a special howto with complain_on_overflow set to complain_overflow_dont. This is used in place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16 relocations. bfd/ChangeLog: PR 28735 * elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define. (or1k_elf_relocate_section): Use new howto instead of trying to mask out relocation bits. |