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.
