Re: binutils ld and new PT_GNU_PROPERTY segment

["Fangrui Song via binutils" <binutils at sourceware dot org>]

On 2020-02-18, H.J. Lu wrote:
> On Tue, Feb 18, 2020@4:38 AM Mark Wielaard <mark@klomp.org> wrote:
> > Hi,
> >
> > binutils 2.32 ld emits a new PT_GNU_PROPERTY (PT_LOOS + 0x474e553)
> > segment that overlaps with the PT_NOTE segment covering the
> > .note.gnu.property section data.
> >
> > I cannot tell if this is an accident/experiment that happened to end up
> > in a release or if it is proposed as an official new segment type.
>
> https://sourceware.org/ml/gnu-gabi/2018-q4/msg00027.html
> https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
>
> > As far as I can tell binutils ld is the only linker which adds this
>
> Annita, does lld generate PT_GNU_PROPERTY segment with CET? If not,
> it is an lld bug.
>
> > extra segment and there is no runtime loader which uses it. It doesn't
> > provide any new information that cannot be found in the existing
> > PT_NOTE segment.
>
> Kernel loader uses it for both ARM and x86.
>
> > On 64 bit architectures it simply covers the extra existing PT_NOTE
> > with 8 byte alignment (normal PT_NOTE segments are 4 byte aligned). On
> > 32bit architectures it covers a sub-range of the existing PT_NOTE
> > segment.
> >
> > It isn't clear to me how other tools should handle this. It seems to
> > prevent normal merging of note sections. Since some notes are probably
> > special if they need to be covered by this new segment type. And it
> > isn't clear how the linker knows which of the SHT_NOTE sections is what
> > needs to be covered by the new segment type. Or is the idea that this
> > will eventually come with a new section type too and GNU properties
> > will no longer use NOTE sections?
>
> PT_GNU_PROPERTY covers .note.gnu.property section.

https://reviews.llvm.org/D70961 added PT_GNU_PROPERTY support to lld.
The change will be included by lld 10.0.0 (currently at rc2).

https://reviews.llvm.org/D70959 added the dump support to llvm-readelf -l and
llvm-objdump -p.
The change will be included by LLVM 10.0.0 (currently at rc2).

From what I can see, neither the Linux kernel nor glibc uses PT_GNU_PROPERTY.
glibc/sysdeps/x86/dl-prop.h parses PT_NOTE.

I tend to agree with Cary
(https://sourceware.org/ml/gnu-gabi/2018-q4/msg00036.html) that
.note.gnu.property should have been designed as a different section type
because its combining semantics are different from other notes
(we could apply "Rules for Linking Unrecognized Sections" to all
SHT_NOTE sections) but it is too late to change the section type.

A separate segment type (PT_GNU_PROPERTY) looks fine to me.
glibc should probably be updated to parse PT_GNU_PROPERTY instead.

(Recently I read some ABI decisions and I noticed that I frequently see
the term "it is too late". As a contributor of both lld and LLVM binary
utilities (and the implementer of a bunch of GNU_PROPERTY changes), I
hope that the LLVM community can be informed of such changes earlier.  A
lot of people are not subscribed to any of the mailing lists (recently I
visit the archives from time to time).

Looks like Annita's job? :) )