https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #34 from mintsuki <mintsuki at protonmail dot com> --- (In reply to H.J. Lu from comment #33) > (In reply to mintsuki from comment #32) > > (In reply to H.J. Lu from comment #31) > > > (In reply to mintsuki from comment #30) > > > > Basically, it tries to find a PHDR which contains the RELA section, and > > > > if > > > > it find it, it subtracts the PHDR's virtual address and adds its offset > > > > in > > > > order to find the offset of the RELA section inside the ELF file itself. > > > > > > In glibc, we know it is a static PIE. We relocate PT_DYNAMIC segment > > > only if > > > it is ET_DYN. > > > > So what is the issue? And in any case, it doesn't feel right to me to have > > This is only after my patch: > > https://patchwork.sourceware.org/project/glibc/list/?series=34373 > > Currently glibc relocates PT_DYNAMIC segment unconditionally. > > > this behaviour in ld just to work around quirks of a specific ELF loader out > > of many. > > > > If anything, it needs to be handled in glibc, and the behaviour of ld should > > be reverted to match gold and lld. > > > > 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 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 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... -- You are receiving this mail because: You are on the CC list for the bug.
