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. 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 -- You are receiving this mail because: You are on the CC list for the bug.
