Hi,
Christoph helped me to get access to a s390x machine - I wasn't able to
reproduce exactly the error he hit. Initially all tests passed, but
after recompiling with build flags more similar to Christop's I was able
to hit another instance of what I assume to be the same bug.
I am fairly sure that I see the problem. Before a post LLVM 10 change
the "runtime linker" for JITed code only asserted that relocations that
need to be performed are of a known type. Since the debian build -
correctly - uses a release version of LLVM, this results in unhandled
relocations basically being resolved to 0.
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).
Greetings,
Andres Freund
