public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: generic-abi@googlegroups.com
Cc: gnu-gabi@sourceware.org
Subject: Re: What integer type should ELF note header have?
Date: Sun, 01 Jan 2017 00:00:00 -0000	[thread overview]
Message-ID: <1513983253.3236.38.camel@klomp.org> (raw)
In-Reply-To: <CAMe9rOosYw=9kF8eTUnxwQXNguvCrcK5GSaM=vbUUSA6+J49Zw@mail.gmail.com>

Hi,

Note that gnu-gabi drops HTML emails. Please use plain text.

On Fri, 2017-12-22 at 03:49 -0800, H.J. Lu wrote:
> On Dec 22, 2017 6:22 AM, "Mark Wielaard" <mark@klomp.org> wrote:
> > It is not really OK. I have seen code that marks an ELF file as
> > invalid and/or gives up processing ELF notes if it contains notes 
> > that don't follow the standard 4-byte alignment/layout rules.
> > So this really impacts any tool that processes any ELF note.
> 
> The unfixed tools won't be able to understand the property
> note, one way or the other. The real question if all note consumers
> should be updated to check the note alignment specified by
> section/segment header.
> When they are updated, what should they do
> if they see 0,1,4,8 alignment?

That is not the real question. Of course if you introduce a new note
type or a new note section/segment type existing users need to be
updated to take advantage of the new type. But you are proposing to
stuff data into SHT_NOTE sections/PT_NOTE segments that cannot be
parsed at all without changes. So to existing tools it is just an
invalid ELF file with garbage data. That is the problem.

The real question is why you need a new note data layout. If the answer
to that is really that you cannot use the existing structure then the
real question is where we are going to store your new data layout. It
shouldn't go into a SHT_NOTE section or PT_NOTE segment, because that
will break existing tools. But we could certainly introduce SHT_NOTE64
and PT_NOTE64 to store such new note types.

> > The simplest really is to just use the normal note
> > alignment/layout. This seems to be what Fedora rawhide toolchain
> > currently does for NT_GNU_PROPERTY_TYPE_0. That way all tools can
> > process the note and the only thing you need to be careful for is
> > that some values in the note descriptor might not be naturally
> > aligned. This really shouldn't be an issue, especially not if this
> > is x86-only anyway.
> 
> The specification isn't x86 specific.

What in the specification requires you to change the existing ELF note
data layout? It seems the current layout as used in Fedora rawhide
works just fine. You keep saying you like to have naturally aligned
data in the note description. And I agree that would be a nice to have.
But it seems hardly so important to break the current format.

Cheers,

Mark

      parent reply	other threads:[~2017-12-22 22:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMe9rOoV5u263JotP=XpiYEzcnjCJOG3U-0X5bnK-WwZoOKTQA@mail.gmail.com>
     [not found] ` <99c8440b-54d8-41bc-6e4d-cd1894536bb7@Oracle.COM>
     [not found]   ` <CAJimCsHE8cMY8MY=BYyQ+o4b14LtQKa2u+SiXWi1o4zBQB9t9Q@mail.gmail.com>
2017-01-01  0:00     ` Suprateeka R Hegde
2017-01-01  0:00       ` Ali Bahrami
2017-01-01  0:00       ` Ali Bahrami
2017-01-01  0:00         ` Mark Wielaard
2017-01-01  0:00           ` H.J. Lu
2017-01-01  0:00             ` Mark Wielaard
2017-01-01  0:00               ` H.J. Lu
2017-01-01  0:00                 ` Mark Wielaard
2017-01-01  0:00                   ` H.J. Lu
2017-01-01  0:00                     ` Mark Wielaard
2017-01-01  0:00                       ` H.J. Lu
     [not found]                   ` <3704867e-58b8-3da1-2b29-959ad67a540d@Oracle.COM>
     [not found]                     ` <1513355861.15696.95.camel@klomp.org>
     [not found]                       ` <CAMe9rOrAFX5gPCB355A=vP0VpWQT1x8V3Hrttxm5ZRsvG1FXXw@mail.gmail.com>
2017-01-01  0:00                         ` Mark Wielaard
     [not found]                           ` <CAMe9rOosYw=9kF8eTUnxwQXNguvCrcK5GSaM=vbUUSA6+J49Zw@mail.gmail.com>
2017-01-01  0:00                             ` Mark Wielaard [this message]

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=1513983253.3236.38.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=generic-abi@googlegroups.com \
    --cc=gnu-gabi@sourceware.org \
    /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).