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