Re: binutils ld and new PT_GNU_PROPERTY segment

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Wed, 2020-02-19 at 11:29 -0800, H.J. Lu wrote:
> On Wed, Feb 19, 2020 at 10:27 AM Fangrui Song <i@maskray.me> wrote:
> > One way to make things follow the spirit of https://sourceware.org/ml/gnu-gabi/2018-q4/msg00036.html
> > 
> > * Define SHT_GNU_PROPERTY
> > * Set sh_type(.note.gnu.property) to SHT_GNU_PROPERTY
> > * Place SHT_GNU_PROPERTY sections in a PT_GNU_PROPERTY segment
> > 
> > The generated PT_NOTE will not include .note.gnu.property, so the scheme is compatible with old loaders (ld.so, gdb, Linux, etc).
> > New loaders should interpret PT_GNU_PROPERTY, instead of PT_NOTE.
> >    ( https://patchwork.kernel.org/patch/11285409/ needs no change)
> > 
> > This way linkers can keep treating SHT_NOTE sections as opaque and apply "Rules for Linking Unrecognized Sections" (http://www.sco.com/developers/gabi/latest/ch4.sheader.html ) when combining SHT_NOTE sections. At least for lld, there will be no special rules for input SHT_NOTE sections.
> > 
> > I will be happy to make changes to lld and LLVM binary utilities if this
> > scheme reaches consensus.
> 
> It is kind of too late now.

This code isn't in the kernel yet. So either it gets changed to use the
existing scheme with gnu property notes found through PT_NOTE to work
with existing binaries. Then there is no need for PT_GNU_PROPERTY
headers.

Or some future kernel will start using PT_GNU_PROPERTY headers to find
the gnu property notes. But that means it won't work with existing
binaries that do not have that header. So there is no backwards
compatibility anyway and we can define SHT_GNU_PROPERTY like above.

So this actually seems the perfect time to make this decision.

Cheers,

Mark