[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0

[mintsuki at protonmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31795

--- Comment #6 from mintsuki <mintsuki at protonmail dot com> ---
(In reply to H.J. Lu from comment #4)
> (In reply to mintsuki from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > It is done to ensure that PIE is loaded at the specific address which may
> > > be required for functional, performance or security purposes.
> > 
> > This does not match what all the other major linkers do (LLD, gold). It also
> > isn't properly documented anywhere that I could find. Additionally, why
> > would someone generate a PIE just for it to be loaded *always* at the same
> > specified address? What is the use case?
> 
> A program may work properly only when it is loaded above 4GB address.

Yes, and I guess that could be explicitly specified as the functioning of a
non-0 load
address.
But that doesn't mean the program needs to always be loaded at the specific
load address.
For example, my kernel's load address is 0xffffffff80000000, aka the top 2GiB
of address
space, but it can be relocated to anywhere in the range from there to the top
of the
address space (as long as it fits), for things like, for example, KASLR.

Setting the load address to 0 works, the bootloader can relocate the kernel to
at or above
0xffffffff80000000, but this makes debugging with KASLR disabled more annoying
as one has
to subtract the slide from addresses passed to addr2line, or tell GDB about the
slide.

> 
> > From what I know, if a PIE has a specific non-0 load address, it should be
> > taken as a hint or preferred load address, but then the program loader
> > should be able to apply any slide to it as it sees fit.
> 
> If a PIE doesn't care where to load, set the load address to 0.

See above.

-- 
You are receiving this mail because:
You are on the CC list for the bug.