https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #36 from mintsuki <mintsuki at protonmail dot com> --- (In reply to H.J. Lu from comment #35) > (In reply to mintsuki from comment #34) > > > > The static PIE generated by ldd with non-zero load address won't work with > > > glibc before and after my glibc fix. I will open an lld issue after glibc > > > is fixed. > > > > I *strongly* disagree with this. > > > > Why are glibc implementation details dictating how ld.bfd operates? Where > > This is how ELF works on Linux. Well, ELF is not Linux specific, though. > > > does it say non-0 load addresses for static-PIE/PIE are not allowed in the > > ELF specification? If it is allowed, why is ld.bfd not allowing me to do it > > Static PIE isn't the part of ELF spec. There was a discussion: > > https://groups.google.com/g/generic-abi/c/mBKlSNldFW4/m/GRddmWGGBQAJ > Then what is ld.bfd following, exactly? Just what Linux/glibc wants? How loosely specified (or not at all) can this be? > > despite Limine accepting this form of ELF files just fine? > > > > At least please consider adding a flag or linker script directive to > > manually set the ELF type... > > That will generate the wrong static PIE with non-zero load address. You > should > check DF_1_PIE for PIE, not ET_DYN. Limine already does that. The algorithm for determining whether an ELF is relocatable or not is at https://github.com/limine-bootloader/limine/blob/c204af454fc9c11b8ef3633664b6e03817c33ff1/common/lib/elf.c#L148-L181 If that was the case, you could've said it earlier and it would've saved the time for this discussion. I still do not like this, but it never caused issues to me or Limine or Limine users. It's just a purely technical argument, because ld.bfd diverged in behaviour compared to other linkers in a silly way. Now I see that this is done to make Linux/glibc happy, and thus unlikely to be fixed or reverted. -- You are receiving this mail because: You are on the CC list for the bug.
