Hi,
On 2020-10-14 14:58:35 -0700, Andres Freund wrote:
> I suspect that building with LDFLAGS="-Wl,-z,relro -Wl,-z,now" - which
> is what I think the debian package does - creates the types of
> relocations that LLVM doesn't handle for elf + s390.
>
> 10 release branch:
>
> void RuntimeDyldELF::resolveSystemZRelocation(const SectionEntry &Section,
> uint64_t Offset, uint64_t Value,
> uint32_t Type, int64_t Addend) {
> uint8_t *LocalAddress = Section.getAddressWithOffset(Offset);
> switch (Type) {
> default:
> llvm_unreachable("Relocation type not implemented yet!");
> break;
>
> 11/master:
>
> void RuntimeDyldELF::resolveSystemZRelocation(const SectionEntry &Section,
> uint64_t Offset, uint64_t Value,
> uint32_t Type, int64_t Addend) {
> uint8_t *LocalAddress = Section.getAddressWithOffset(Offset);
> switch (Type) {
> default:
> report_fatal_error("Relocation type not implemented yet!");
> break;
>
> Verifying that that's the case by rebuilding against 11 (and then an
> LLVM debug build, which will take a day or two).
Oh dear. It's not as simple as that. The issue indeed are relocations,
but we don't hit those errors. The issue rather is that the systemz
specific relative redirection code thought that the only relative
symbols are functions. So it creates a stub function to redirect
them. Which turns out to not work well with variables like
CurrentMemoryContext...
Example debug output:
This is a SystemZ indirect relocation. Create a new stub function
RelType: 20 Addend: 2 TargetName: ExecAggInitGroup
SectionID: 0 Offset: 624
This is a SystemZ indirect relocation. Create a new stub function
RelType: 26 Addend: 2 TargetName: CurrentMemoryContext
SectionID: 0 Offset: 712
Opening a bug report...
Greetings,
Andres Freund