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
On 2020-02-19, H.J. Lu wrote:
On Wed, Feb 19, 2020 at 10:27 AM Fangrui Song <i@maskray.me> wrote:
On 2020-02-19, H.J. Lu wrote:
>On Wed, Feb 19, 2020 at 5:17 AM Mark Wielaard <mark@klomp.org> wrote:
>>
>> On Wed, 2020-02-19 at 04:28 -0800, H.J. Lu wrote:
>> > On Wed, Feb 19, 2020 at 4:02 AM Mark Wielaard <mark@klomp.org> wrote:
>> > > > https://patchwork.kernel.org/patch/11285409/
>> > > >
>> > > > It is for both x86 and arm64.
>> > >
>> > > So that is not upstream in the mainline kernel? Why can't that patch
>> > > use the existing PT_NOTE segment? That would make it compatible with
>> > > existing binaries that don't have this PT_GNU_PROPERTY program header.
>> >
>> > Kernel loader is one of motivations of PT_GNU_PROPERTY. Kernel loader
>> > only wants to check PT_XXX.
>>
>> So they can check PT_NOTE because it provides the same information and
>> is already available in existing binaries.
>>
>
>Please take a look at glibc note.gnu.property parser. It is very complicated to
>check for invalid .note.gnu.property sections generated by the older
>linkers with
>the new object. Kernel loader doesn't want to do it.
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.
Better late than never. It is never late to fix the section type if we do intend to fix it.
Loaders don't read sections => the section type change is backward compatible.
On 2020-02-20, H.J. Lu wrote:
On Thu, Feb 20, 2020 at 1:37 AM Mark Wielaard <mark@klomp.org> wrote:
Hi,
On Wed, 2020-02-19 at 14:17 -0800, H.J. Lu wrote:
> On Wed, Feb 19, 2020 at 1:46 PM Mark Wielaard <mark@klomp.org> wrote:
> > 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.
>
> Binaries with .note.gnu.property section have been put into many
> OS releases. We must support them.
We can teach newer assemblers to emit SHT_GNU_PROPERTY.
Newer linkers can support both SHT_GNU_PROPERTY/SHT_NOTE .note.gnu.property
At some point in the future, linkers can drop support for SHT_NOTE .note.gnu.property
Then it will become a graceful degradation: the old SHT_NOTE object files will not be
different from older object files without .note.gnu.property
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.
The current PT_GNU_PROPERTY usage is all about hints. They are "nice to have" but not
"necessary to have". I don't see any problem teaching newer loaders to forget
PT_NOTE, if we do think PT_GNU_PROPERTY is the way forward.
The currently mixed status is annoying:
glibc: PT_NOTE
Proposed Linux kernel patch: PT_GNU_PROPERTY