bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when lo


From: mintsuki at protonmail dot com
Subject: [Bug ld/31795] ld.bfd makes ELFs of type ET_EXEC for static PIEs when load address is non-0
Date: Sun, 26 May 2024 15:50:51 +0000

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

--- Comment #36 from mintsuki <mintsuki at protonmail dot com> ---
(In reply to H.J. Lu from comment #35)
> (In reply to mintsuki from comment #34)
> 
> > > 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
> 
> This is how ELF works on Linux.

Well, ELF is not Linux specific, though.

> 
> > 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
> 
> Static PIE isn't the part of ELF spec. There was a discussion:
> 
> https://groups.google.com/g/generic-abi/c/mBKlSNldFW4/m/GRddmWGGBQAJ
> 

Then what is ld.bfd following, exactly? Just what Linux/glibc wants? How
loosely specified (or not at all) can this be?

> > 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...
> 
> That will generate the wrong static PIE with non-zero load address.  You
> should
> check DF_1_PIE for PIE, not ET_DYN.

Limine already does that. The algorithm for determining whether an ELF is
relocatable or not is at
https://github.com/limine-bootloader/limine/blob/c204af454fc9c11b8ef3633664b6e03817c33ff1/common/lib/elf.c#L148-L181

If that was the case, you could've said it earlier and it would've saved the
time for this discussion. I still do not like this, but it never caused issues
to me or Limine or Limine users. It's just a purely technical argument, because
ld.bfd diverged in behaviour compared to other linkers in a silly way.

Now I see that this is done to make Linux/glibc happy, and thus unlikely to be
fixed or reverted.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]