public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Ali Bahrami <Ali.Bahrami@Oracle.COM>
To: hegdesmailbox@gmail.com, generic-abi@googlegroups.com,
	       Cary Coutant <ccoutant@gmail.com>,
	"H.J. Lu" <hjl.tools@gmail.com>,
	       Mark Mentovai <mark@chromium.org>
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: <f9194708-5cc8-4924-0cf4-686c9abe1b47@Oracle.COM> (raw)
In-Reply-To: <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com>

    This discussion has sprawled a bit, as we tried to figure out
how we've gotten where we are. So let me try to boil it down to
the basic facts, as I understand them:

Supra has confirmed that HP-UX implemented ELFCLASS64 notes using
64-bit words for the name, descsz, and type fields.

Solaris, and Linux, and based on Ian's comment in gold, NetBSD
(I imagine any GNU toolchain) use 32-bit words, and always set
alignment 4. We're all been essentially putting ELFCLASS32 notes
into our ELFCLASS64 objects. This hasn't caused trouble, and therefore
went unnoticed, until recently when H.J tried to reconcile the
issues caused by his recent introduction of NT_GNU_PROPERTY_TYPE_0,
which has an actual need for 64-bit alignment.

Given that we have so many existing 64-bit objects out in the
field with 32-bit notes, I think we have to hold our noses and fix
the gABI to allow it. That means removing the ELFCLASS as determining
the note class, and instead tying it to the section header's
sh_addralign. That's not pretty, but it's workable.

That leaves the issue of the wordsize for the namesz, descsz,
and type fields. H.J, when you pointed me at the fact that Linux
uses 32-bit words for this, you said:

     > We have the same note header format for both 32-bit and 64-bit notes.
     > Here Elf32 stands for 32-bit ELF object, not for 32-bit ELF note.  The same
     > is true for Elf64.  We want to avoid changing it.

I don't blame you, but I still think that might be the best thing.

To my reading, the words of the gABI support what HP-UX did, and the
comment in the Solaris code makes me think our definition of ELF64_Nhdr
was a mistake. And given that the rest of us don't have any installed
base (yet) of 8 byte alignment notes, it seems that the most compatible
thing that we could do would be to also use 8-byte words for these fields.
triggered by an sh_addralign, or p_align, of 8. That seems to match the
gABI words, and preserves interoperability with HP-UX.

An open question to you and Mark, and any others in the GNU world:
Would you consider making that change? If so, I think we (Solaris)
would have no problem in doing likewise.

I'd also like to hear from anyone representing any other ELF implementations
who might have a conflict with this.

Once we have a rough agreement, I'll put together a rewrite of the gABI
Note Section that might replace what's there.

Thanks.

- Ali

  reply	other threads:[~2017-12-11  5:32 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 [this message]
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
     [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
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       ` Ali Bahrami

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=f9194708-5cc8-4924-0cf4-686c9abe1b47@Oracle.COM \
    --to=ali.bahrami@oracle.com \
    --cc=ccoutant@gmail.com \
    --cc=generic-abi@googlegroups.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=hegdesmailbox@gmail.com \
    --cc=hjl.tools@gmail.com \
    --cc=mark@chromium.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).