[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 #10 from mintsuki <mintsuki at protonmail dot com> ---
(In reply to H.J. Lu from comment #8)
> (In reply to mintsuki from comment #7)
> > (In reply to H.J. Lu from comment #5)
> > > (In reply to mintsuki from comment #3)
> > > > Also, when generating a shared object with -shared, without -pie, 
> > > > having a
> > > > non-0 base address does not affect the ELF file type, which is always
> > > 
> > > You can't load the multiple shared libraries at the overlapping address
> > > range.
> > > 
> > > > ET_DYN. If what you just said is true, then why is this the behaviour 
> > > > here
> > > > and not when making a static PIE?
> > > 
> > > A testcase?
> > 
> 
> I was asking a testcase of static PIE where ELF type wasn't EXEC when a load
> address was specified.

There is no such case for ld.bfd. I never said there was, sorry if I wasn't
clear enough. That said, lld and gold both allow for such case as previously
mentioned.

What I believe the bug consists of is the behaviour of ld.bfd not aligning with
the other linkers. I think it makes perfect sense for an ET_DYN static PIE with
non-0 load address to exist, as previously mentioned, and I believe the bug is
ld.bfd not allowing this.

If this is policy, then I believe it should be properly documented somewhere,
if it wasn't already, and then ld.gold (as part of GNU binutils) should be
changed to match ld.bfd's behaviour. Though I hope this isn't done as I
consider ld.gold's (and LLD's) behaviour to be the preferrable one.

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