Re: gs_group_1 crashing on 13beta2/s390x
От | Andres Freund |
---|---|
Тема | Re: gs_group_1 crashing on 13beta2/s390x |
Дата | |
Msg-id | 20201014215835.xqllzcbj6yulvexa@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: gs_group_1 crashing on 13beta2/s390x (Christoph Berg <myon@debian.org>) |
Ответы |
Re: gs_group_1 crashing on 13beta2/s390x
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: