From: Mark Wielaard <mark@klomp.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Rahul Chaudhry via gnu-gabi <gnu-gabi@sourceware.org>,
Binutils <binutils@sourceware.org>,
"Zhang, Annita" <annita.zhang@intel.com>
Subject: Re: binutils ld and new PT_GNU_PROPERTY segment
Date: Wed, 01 Jan 2020 00:00:00 -0000 [thread overview]
Message-ID: <4a2518534d4b3b1ac66cad20251588df00969741.camel@klomp.org> (raw)
In-Reply-To: <CAMe9rOqCJVw2okDr0gonHWpxEVw+qO8uYLjbzxihB4tx-JuJ6g@mail.gmail.com>
Hi,
On Tue, 2020-02-18 at 04:48 -0800, H.J. Lu wrote:
> On Tue, Feb 18, 2020 at 4:38 AM Mark Wielaard <mark@klomp.org> wrote:
> > 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
I see you added it, but I don't see consensus for it. It also doesn't
really make sense if it still uses the same section type and has to
rely on a magic section name.
> > 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.
I think it is the other way around, binutils ld generates it, but
nobody uses it, it is redundant and the interaction with other tools
dealing with SHT_NOTE sections isn't really clear.
> > 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.
I cannot find it. Could you point to where it uses it?
Why doesn't it simply use the PT_NOTE segment?
> > 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.
Using magic section names is a problem. It means other tools can no
longer rely on the section type.
Can we please simply remove this because it isn't used, doesn't provide
any new information, depends on magic section names and makes it harder
for other tools to deal with generic SHT_NOTE sections.
Thanks,
Mark
next prev parent reply other threads:[~2020-02-19 10:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-01 0:00 Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard [this message]
2020-01-01 0:00 ` Fangrui Song via gnu-gabi
2020-01-01 0:00 ` Zhang, Annita
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` H.J. Lu
2020-01-01 0:00 ` Mark Wielaard
2020-01-01 0:00 ` Fangrui Song
2020-04-01 8:46 ` Florian Weimer
2020-04-01 9:22 ` Szabolcs Nagy
2020-04-01 9:29 ` Florian Weimer
2020-04-01 10:10 ` Szabolcs Nagy
2020-04-01 10:21 ` Florian Weimer
2020-01-01 0:00 ` Fangrui Song
2020-01-01 0:00 ` H.J. Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a2518534d4b3b1ac66cad20251588df00969741.camel@klomp.org \
--to=mark@klomp.org \
--cc=annita.zhang@intel.com \
--cc=binutils@sourceware.org \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).