Re: gs_group_1 crashing on 13beta2/s390x

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