[Bug ld/21464] relocation truncated to fit: R_OR1K_GOT16 on OpenRISC, when linking libQtGui.so.4.8.7

[shorne at gmail dot com]

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.