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

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to mintsuki from comment #6)
> (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.

GDB has no problems to debug PIE with load address == 0.  Is this issue
specific
to kernel?

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