public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "H.J. Lu" <hjl.tools@gmail.com>, Fangrui Song <i@maskray.me>
Cc: 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: <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> (raw)
In-Reply-To: <CAMe9rOrWFu9QUb_q6UjaH5Av_CMoBCaXCj1Z_chUTDqQ4YaY=g@mail.gmail.com>

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

  reply	other threads:[~2020-02-19 21:46 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   ` 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 [this message]
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                               ` 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   ` Mark Wielaard

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=2e29243995903cf2d52975543675f2b92fa1e201.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).