https://sourceware.org/bugzilla/show_bug.cgi?id=31795
--- Comment #57 from mintsuki <mintsuki at protonmail dot com> --- (In reply to H.J. Lu from comment #55) > (In reply to mintsuki from comment #54) > > (In reply to H.J. Lu from comment #52) > > > (In reply to H.J. Lu from comment #51) > > > > (In reply to mintsuki from comment #50) > > > > > > > > > > Why can't you check DF_1_PIE for PIE? > > > > > > > > > > That is what I do now, but to check for *relocatability*. PIE in and > > > > > of > > > > > itself is not something that tells me whether I should relocate (for > > > > > KASLR > > > > > for example) or not. That is what you just said. > > > > > > > > If DF_1_PIE is set, the binary can be relocated to any address. What > > > > did I > > > > miss? > > > > > > The first PT_LOAD segment has non-0 p_vaddr, the program may misbehave if > > > the load address != p_vaddr. > > > > How is this possible? Under which circumstances? It works fine with all the > > other linkers for me. > > It works for your programs doesn't mean that it works all programs some of > which > won't correctly if ET_DYN is used. Which? Under which circumstances? Do you have an example that doesn't involve Linux/glibc? Is this an actual ELF/toolchain issue, or is it some Linux/glibc specific issue? If the latter is the case, why on earth is this being worked around in binutils rather than fixed in Linux/glibc? -- You are receiving this mail because: You are on the CC list for the bug.
