From: Mark Wielaard <mark@klomp.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Fangrui Song <i@maskray.me>, Cary Coutant <ccoutant@gmail.com>,
"Zhang, Annita" <annita.zhang@intel.com>,
"Liu, Hongtao" <hongtao.liu@intel.com>,
gnu-gabi <gnu-gabi@sourceware.org>,
Binutils <binutils@sourceware.org>
Subject: Re: binutils ld and new PT_GNU_PROPERTY segment
Date: Wed, 01 Jan 2020 00:00:00 -0000 [thread overview]
Message-ID: <a6752f00b3e0e0eb799c840b3b991a9730c9c86b.camel@klomp.org> (raw)
In-Reply-To: <CAMe9rOpWbU=rMb62mgqLFsHFTHfq8VQO7BfG4Codkrqh_b1x5Q@mail.gmail.com>
Hi,
On Thu, 2020-02-20 at 03:51 -0800, H.J. Lu wrote:
> On Thu, Feb 20, 2020 at 1:37 AM Mark Wielaard <mark@klomp.org> wrote:
> > On Wed, 2020-02-19 at 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.
Please lets either really keep things as they are or redesign things
based on PT_GNU_PROPERTY and a new section type.
Thanks,
Mark
next prev parent reply other threads:[~2020-02-20 22:43 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
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 ` 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 [this message]
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
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=a6752f00b3e0e0eb799c840b3b991a9730c9c86b.camel@klomp.org \
--to=mark@klomp.org \
--cc=annita.zhang@intel.com \
--cc=binutils@sourceware.org \
--cc=ccoutant@gmail.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=hongtao.liu@intel.com \
--cc=i@maskray.me \
/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).