[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What integer type should ELF note header have?



   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