bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/30824] BFD (GNU Binutils) 2.41 internal error, aborting at elf64


From: amodra at gmail dot com
Subject: [Bug ld/30824] BFD (GNU Binutils) 2.41 internal error, aborting at elf64-ppc.c:17531 in ppc64_elf_relocate_section
Date: Tue, 16 Jan 2024 01:29:44 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=30824

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
The test is saying "If this isn't a reloc handled in a DT_RELR section, then it
needs to be output as a normal dynamic reloc".  So...  A DT_RELR section is a
compressed set of RELATIVE relocs.  Possible relr relocs are those that start
as R_PPC64_ADDR64 or R_PPC64_TOC, and are sufficiently aligned since the relr
output encoding doesn't allow for relr at odd addresses.  I haven't built
FreeRDP to see what is going on (at the moment I'd need to know how to
cross-compile from x86_64 to ppc64le, and I don't have much of a clue about
cmake builds) but it is obvious from Nick's patch that we have an ADDR64 reloc
on a multiple of 2 or 4 address against a symbol that is local to the library. 
These aren't sufficiently aligned to be RELATIVE relocs, but could be encoded
as RELR.  Thus there is a counting problem: Code prior to relocate_section says
make space for a relr entry and *not* one of the usual dynamic relocs, while
relocate_section says it is a one of the usual dynamic relocs.

Nick, I think your patch isn't quite correct.  Allowing a UADDR64 output reloc
match would also need to test a bunch of things about the symbol, ie. the same
things that are tested for RELATIVE relocs minus the stricter alignment.  It
might be simpler to bump the RELR alignment requirement everywhere in
elf64-ppc.c.

I'll write a patch to do that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]