[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

mintsuki <mintsuki at protonmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #19 from mintsuki <mintsuki at protonmail dot com> ---
Why are shared libraries (linked with -shared) allowed to have a non-0 load
address? Is this a bug or is this intended behaviour? If it is intended
behaviour, then what is said behaviour? Why would said behaviour be any
different compared to a -pie with a non-0 load address?

I am sorry for my insistence, it's just that I strongly feel like forcing the
ELF type to ET_EXEC with non-0 load addresses is a bug; a workaround for a
specific situation from 10 years ago that should've never been added... Even
the documentation you added doesn't really make anything clear, as it makes
assumptions about the loader that are not necessarily what the ELF
specification mandates, as far as I can tell.

To be more specific, I am the author and main developer of the Limine
bootloader; the Limine bootloader has its own boot protocol supporting loading
64-bit ELF files. When loading relocatable ELFs, so far what I had to do was
ignore the ET_EXEC file type and instead rely on the presence of the DF_1_PIE
flag (which your linker emits anyways even if the ELF type is forced to
ET_EXEC) to determine whether an ELF file is relocatable or not (if the type
wasn't ET_DYN already).

This is because ld.bfd refuses to generate PIE ELFs with a non-0 base and
ET_DYN type.

There are solutions like recommending people to generate shared objects instead
of PIEs, but I feel like that's almost like relying on a workaround to avoid
the workaround, and I do not like that.

The other solution was what I thought about doing first, which is to set the
load address to 0; but as I mentioned before, that breaks addr2line, objdump,
and friends if looking for the raw virtual address of something...

Is this workaround in ld.bfd *really* still necessary after 10 years from when
it was added? Can you please strongly consider reverting this behaviour? I
would be extremely grateful if that was done.

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