This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binutils ld and new PT_GNU_PROPERTY segment
+ libc-alpha
On 2020-02-20, Mark Wielaard wrote:
Hi,
On Thu, 2020-02-20@03:51 -0800, H.J. Lu wrote:
On Thu, Feb 20, 2020@1:37 AM Mark Wielaard <mark@klomp.org> wrote:
> On Wed, 2020-02-19@14:17 -0800, H.J. Lu wrote:
> >
> > Binaries with .note.gnu.property section have been put into many
> > OS releases. We must support them.
>
> OK. Then it is option 1. The kernel will need to support PT_NOTE for
> parsing the properties, since such older binaries won't have a
> PT_GNU_PROPERTY program header. Then we can simply get rid of
> PT_GNU_PROPERTY since nobody uses it and all information is already
> available through the PT_NOTE segment.
>
Kernel loader only checks ld.so and static executable. Re-link them with
newer linker will get PT_GNU_PROPERTY. But ld.so needs to check
PT_NOTE for older binaries.
Having different loaders check different program headers seems very
confusing. And it doesn't really seem to provide backwards
compatibility since depending on how the code was linked previously you
might still require a rebuild.
Having a mix of PT_NOTE/PT_GNU_PROPERTY segments both based on
SHT_NOTEs, but one of them based on magic section names, makes things
really complicated for other tools.
Agreed. The current (glibc: PT_NOTE; proposed Linux: PT_GNU_PROPERTY) mixed mess is looking for
trouble. Unfortunately we are likely in a situation where we have to revise ABI[0] just because we
did not try hard to get consensus[1][2].
Please lets either really keep things as they are or redesign things
based on PT_GNU_PROPERTY and a new section type.
Thanks,
Mark
Below is my understanding of these matters. Hope they will be useful for
interested stakeholders (for example, AArch64 devs, though PT_GNU_PROPERTY is
currently driven by x86) who don't follow the discussions so closely.
1. We need PT_GNU_PROPERTY.
Old linkers don't know the special processing on input .note.gnu.property sections.
The output .note.gnu.property does not take -z ibt/-z shstk/-z force-bti/-z pac-plt into account =>
invalid.
The produced PT_NOTE may contain multiple NT_GNU_PROPERTY_TYPE_0 => invalid [3]
Also note that sh_addralign(.note.gnu.property)=8 on a 64-bit platform,
while sh_addralign(.note.gnu.build-id)=sh_addralign(.note.ABI-tag)=...=4 (ancient mistake made by
at least Linux/FreeBSD/NetBSD/...) GNU ld before PR ld/23658 may create corrupted PT_NOTE.
For at least the above reasons, loaders are better not interpreting PT_NOTE.
glibc/sysdeps/x86/dl-prop.h is currently interpreting PT_NOTE => it should be fixed.
Given point 1 and 3, this comment deserves a reconsideration:
> Binaries with .note.gnu.property section have been put into many
> OS releases. We must support them.
2. .note.gnu.property behaves strangely, unlike a regular SHT_NOTE.
For a .note.gnu.property aware linker (newer GNU ld, newer lld),
.note.gnu.property input sections are dropped.
(We have .note.GNU-stack and .note.GNU-split-stack which both require special processing, but
they are SHT_PROGBITS.)
3. We need SHT_GNU_PROPERTY.
The output .note.gnu.property being SHT_NOTE causes linkers to place the section in both PT_NOTE
and PT_GNU_PROPERTY.
PT_NOTE, as explained by point 1 above, can cause trouble to old loaders.
Have we proved that "older linker-produced concatenated PT_NOTE cannot cause trouble to loaders interpreting PT_NOTE"?
SHT_GNU_PROPERTY does not contribute to PT_NOTE and will not cause any problem to old loaders
interpreting PT_NOTE.
[0]: https://sourceware.org/ml/gnu-gabi/2018-q4/msg00030.html
[1]: https://sourceware.org/ml/gnu-gabi/2018-q4/msg00033.html
[2]: https://sourceware.org/ml/gnu-gabi/2018-q4/msg00037.html
[3]: https://groups.google.com/forum/#!topic/x86-64-abi/LGPTWbMp8hQ