Re: What integer type should ELF note header have?

Re: What integer type should ELF note header have?

[Suprateeka R Hegde]

On 09-Dec-2017 08:11 PM, Cary Coutant wrote:
> I'm pretty sure that at HP, we implemented the 8-byte wording.

That might be in the initial days. I do not have any archive that says
so. The current implementation is extremely very clear. It follows gABI
completely. Its 4 byte word with 4 byte alignment for 32-bit and 8 byte
word with 8 byte alignment for 64-bit. Read below.

On 10-Dec-2017 12:18 AM, Ali Bahrami wrote:
> Would the following work, and be backward compatible on other platforms?

What you mentioned below is exactly what we have on HP-UX too.

> 
>     - The ELFCLASS of an object no longer dictates the wordsize of
>       note sections.
> 
>     - In SHT_NOTE section headers, valid values of sh_addralign are
>       4, or 8. This value specifies the required alignment, as well
>       as the note wordsize, and padding.

Thats precisely what I wrote a week back:

supra wrote:
> And p_align of PT_NOTE may be set to the
> maximum of all sh_addralign of all SHT_NOTE that make up the PT_NOTE.

Since it is unlikely that there could be SHT_NOTE of different
alignments (in the same data model), it boils down to precisely what you
said above.

>       - In PT_NOTE program headers, the p_align field must match the
>         sh_addralign value for the note(s) that it encapsulates, and is
>         expected to be 4 for 32-bit notes, and 8 for 64-bit notes. For
>         historical reasons, values of 0 or 1 are also allowed, and refer
>         to a 32-bit note. 

Looks perfect. I agree.

> I have several reasons for thinking these are intended to be 8 bytes in 64-bit
> notes, starting with the words in the gABI. As HP-UX already implemented this
> years ago, Cary and Supra can confirm or deny that.

> What do other platforms (again, thinking about HP-UX) do for 64-bit notes?

Thats right. Reiterating, its 4 byte word with 4 byte alignment for
32-bit, and 8 byte word with 8 byte alignment for 64-bit.

>     - If those three fields are always 32-bit, then it means that name is
>       aligned on 4 bytes. This complicates the padding of name,

Agree. See below.

On 05-Dec-2017 03:11 AM, Mark Mentovai wrote:
> typedef uint32_t Elf32_Word;
> typedef uint32_t Elf64_Word;

This is the reason why on HP-UX we do not even have that
Elf[64|32]_Nhdr. It would make the word size same for both 32-bit and
64-bit data models. I think even gABI does not define *_Nhdr. Or am I
mistaken?

We generate contents of SHT_NOTE sections using internal data structs
and ensure gABI compatibility in a very simple way.

--
Supra

Re: What integer type should ELF note header have?

[Ali Bahrami]

    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

Re: What integer type should ELF note header have?

[Mark Wielaard]

On Sun, 2017-12-10 at 22:22 -0700, Ali Bahrami wrote:
> 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 am afraid changing ELF64_Nhdr/GElf_Nhdr now from 32bit Words, or
changing the alignment of the namesz or descsz from 4 byte alignment is
 not going to work. It is too hardcoded in various GNU/Linux code bases
now to change. On GNU/Linux ELF notes have been used a lot already, if
only to parse the build-id embedded in every executable. So you will
find a lot of code that will simply do:

/*
 * Align offset to 4 bytes as needed for note name and descriptor data.
 */
#define NOTE_ALIGN(n) (((n) + 3) & -4U)

                GElf_Nhdr *nhdr = ptr;
                size_t namesz = NOTE_ALIGN(nhdr->n_namesz),
                       descsz = NOTE_ALIGN(nhdr->n_descsz);
                const char *name;

                ptr += sizeof(*nhdr);
                name = ptr;
                ptr += namesz;
[...]
                ptr += descsz;

The above is from the linux kernel perf tool (tools/perf/util/symbol-
elf.c), but I can easily find more examples of hard coded parsing of
ELF notes that simply assumes they are 32 bit Words, 4 byte aligned (it
is basically what elfutils libelf also does).

You could play with the SHT_NOTE sh_align and PT_NOTE p_align values,
but I haven't actually found any code that pays attention to it. So a
lot of code would have to be rewritten.

Cheers,

Mark

Re: What integer type should ELF note header have?

[H.J. Lu]

On Mon, Dec 11, 2017 at 1:43 AM, Mark Wielaard <mark@klomp.org> wrote:
> On Sun, 2017-12-10 at 22:22 -0700, Ali Bahrami wrote:
>> 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 am afraid changing ELF64_Nhdr/GElf_Nhdr now from 32bit Words, or

Changing ELF64_Nhdr is going to be hard, but not impossible.  In theory,
an 64-bit object may have a note entry which is bigger than 4 GB.  We
can add a new note header:

typedef struct
{
  Elf64_Xword n_namesz;                  /* Length of the note's name.  */
  Elf64_Xword n_descsz;                  /* Length of the note's descriptor.  */
  Elf64_Xword n_type;                    /* Type of the note.  */
} Elf64_Nhdr64;

Note segments/sections with 8 byte alignment should use Elf64_Nhdr64.
If we want to do it, we should do it now before NT_GNU_PROPERTY_TYPE_0
notes with the existing Elf64_Nhdr are generated by GCC 8 with
-fcf-protection -mcet.

> changing the alignment of the namesz or descsz from 4 byte alignment is

I have updated glibc and binutils to support 4 byte and 8 byte alignments
in 64-bit objects by checking p_align/sh_addralign, instead of assuming
4 byte alignment, like

commit 8d81ce0c6d6ca923571e8b2bac132929f9a02973
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Nov 28 09:56:47 2017 -0800

    Properly compute offsets of note descriptor and next note [BZ #22370]

    A note header has 3 4-bytes fields, followed by note name and note
    descriptor.  According to gABI, in a note entry, the note name field,
    not note name size, is padded for the note descriptor.  And the note
    descriptor field, not note descriptor size, is padded for the next
    note entry.  Notes are aligned to 4 bytes in 32-bit objects and 8 bytes
    in 64-bit objects.

    For all GNU notes, the name is "GNU" which is 4 bytes.  They have the
    same format in the first 16 bytes in both 32-bit and 64-bit objects.
    They differ by note descriptor size and note type.  So far, .note.ABI-tag
    and .note.gnu.build-id notes are always aligned to 4 bytes.  The exsting
    codes compute the note size by aligning the note name size and note
    descriptor size to 4 bytes.  It happens to produce the same value as
    the actual note size by luck since the name size is 4 and offset of the
    note descriptor is 16.  But it will produce the wrong size when note
    alignment is 8 bytes in 64-bit objects.

    This patch defines ELF_NOTE_DESC_OFFSET and ELF_NOTE_NEXT_OFFSET to
    properly compute offsets of note descriptor and next note.  It uses
    alignment of PT_NOTE segment to support both 4-byte and 8-byte note
    alignments in 64-bit objects.  To handle PT_NOTE segments with
    incorrect alignment, which may lead to an infinite loop, if segment
    alignment is less than 4, we treate alignment as 4 bytes since some
    note segments have 0 or 1 byte alignment.

>  not going to work. It is too hardcoded in various GNU/Linux code bases
> now to change. On GNU/Linux ELF notes have been used a lot already, if
> only to parse the build-id embedded in every executable. So you will
> find a lot of code that will simply do:
>
> /*
>  * Align offset to 4 bytes as needed for note name and descriptor data.
>  */
> #define NOTE_ALIGN(n) (((n) + 3) & -4U)
>
>                 GElf_Nhdr *nhdr = ptr;
>                 size_t namesz = NOTE_ALIGN(nhdr->n_namesz),
>                        descsz = NOTE_ALIGN(nhdr->n_descsz);
>                 const char *name;
>
>                 ptr += sizeof(*nhdr);
>                 name = ptr;
>                 ptr += namesz;
> [...]
>                 ptr += descsz;
>
> The above is from the linux kernel perf tool (tools/perf/util/symbol-
> elf.c), but I can easily find more examples of hard coded parsing of
> ELF notes that simply assumes they are 32 bit Words, 4 byte aligned (it
> is basically what elfutils libelf also does).
>
> You could play with the SHT_NOTE sh_align and PT_NOTE p_align values,
> but I haven't actually found any code that pays attention to it. So a
> lot of code would have to be rewritten.
>

These can be easily fixed with

/* Compute the offset of the note descriptor from size of note entry's
   owner string and note alignment.  */
# define ELF_NOTE_DESC_OFFSET(namesz, align) \
  ALIGN_UP (sizeof (ElfW(Nhdr)) + (namesz), (align))

/* Compute the offset of the next note entry from size of note entry's
   owner string, size of the note descriptor and note alignment.  */
# define ELF_NOTE_NEXT_OFFSET(namesz, descsz, align) \
  ALIGN_UP (ELF_NOTE_DESC_OFFSET ((namesz), (align)) + (descsz), (align))

I have added them to glibc, binutils as well as the upcoming kernel
patch to enable CET.

-- 
H.J.

Re: What integer type should ELF note header have?

[Mark Wielaard]

On Mon, 2017-12-11 at 04:11 -0800, H.J. Lu wrote:
> Changing ELF64_Nhdr is going to be hard, but not impossible.  In
> theory, an 64-bit object may have a note entry which is bigger than 4
> GB.  We can add a new note header:
> 
> typedef struct
> {
>   Elf64_Xword n_namesz;                  /* Length of the note's name.  */
>   Elf64_Xword n_descsz;                  /* Length of the note's descriptor.  */
>   Elf64_Xword n_type;                    /* Type of the note.  */
> } Elf64_Nhdr64;
> 
> Note segments/sections with 8 byte alignment should use Elf64_Nhdr64.
> If we want to do it, we should do it now before
> NT_GNU_PROPERTY_TYPE_0
> notes with the existing Elf64_Nhdr are generated by GCC 8 with
> -fcf-protection -mcet.

Yes, I think having a new note type is the way to go, if we want to
change the alignment requirements.

BTW. What is the reason you need 8 byte aligned notes?

One issue we had with ELF notes for systemtap (the stap sdt notes) was
that tools like prelink don't know about addresses inside notes. So we
did end up with (also) using a .stapsdt.base section so we had a
sh_addr that we could compare against in case tools like prelink needed
to adjust needed to do address adjustments.

Another thing about ELF notes is that they normally should be fairly
small because when generating separate .debug files they get copied. So
they take up space in both the main and debug file.

So maybe using a normal ELF section might be an alternative?

> I have updated glibc and binutils to support 4 byte and 8 byte alignments
> in 64-bit objects by checking p_align/sh_addralign, instead of assuming
> 4 byte alignment, like

I looked at those glibc and binutils patch proposals and I must say I
don't get the feeling you really got consensus on them. For both
reviewers said that on GNU/Linux note alignment doesn't follow gabi and
seemed to think it was a bad idea to change that now. I am somewhat
surprised you committed them anyway without more discussion to get
consensus.

> > You could play with the SHT_NOTE sh_align and PT_NOTE p_align
> > values, but I haven't actually found any code that pays attention
> > to it. So a lot of code would have to be rewritten.
> > 
> These can be easily fixed with [...]

But the issue is that the code is not wrong. ELF Notes on GNU/Linux
always have had a fixed 4 byte alignment. That might not be what gabi
intended, but it is what several code bases have been assuming for
decades. If we are going to change that, it really should require new 
ELF note types so consumers current code for existing notes isn't
broken.

Cheers,

Mark

Re: What integer type should ELF note header have?

[H.J. Lu]

On Wed, Dec 13, 2017 at 5:57 AM, Mark Wielaard <mark@klomp.org> wrote:
> On Mon, 2017-12-11 at 04:11 -0800, H.J. Lu wrote:
>> Changing ELF64_Nhdr is going to be hard, but not impossible.  In
>> theory, an 64-bit object may have a note entry which is bigger than 4
>> GB.  We can add a new note header:
>>
>> typedef struct
>> {
>>   Elf64_Xword n_namesz;                  /* Length of the note's name.  */
>>   Elf64_Xword n_descsz;                  /* Length of the note's descriptor.  */
>>   Elf64_Xword n_type;                    /* Type of the note.  */
>> } Elf64_Nhdr64;
>>
>> Note segments/sections with 8 byte alignment should use Elf64_Nhdr64.
>> If we want to do it, we should do it now before
>> NT_GNU_PROPERTY_TYPE_0
>> notes with the existing Elf64_Nhdr are generated by GCC 8 with
>> -fcf-protection -mcet.
>
> Yes, I think having a new note type is the way to go, if we want to
> change the alignment requirements.
>
> BTW. What is the reason you need 8 byte aligned notes?
>

NT_GNU_PROPERTY_TYPE_0 can have 64-bit integer properties
in 64-bit objects.  They should be aligned to 8 bytes.  This is
independent of Elf64_Nhdr.

-- 
H.J.

Re: What integer type should ELF note header have?

[Mark Wielaard]

On Wed, 2017-12-13 at 10:09 -0800, H.J. Lu wrote:
> On Wed, Dec 13, 2017 at 5:57 AM, Mark Wielaard <mark@klomp.org>
> wrote:
> > On Mon, 2017-12-11 at 04:11 -0800, H.J. Lu wrote:
> > > Note segments/sections with 8 byte alignment should use Elf64_Nhdr64.
> > > If we want to do it, we should do it now before
> > > NT_GNU_PROPERTY_TYPE_0
> > > notes with the existing Elf64_Nhdr are generated by GCC 8 with
> > > -fcf-protection -mcet.
> > 
> > Yes, I think having a new note type is the way to go, if we want to
> > change the alignment requirements.
> > 
> > BTW. What is the reason you need 8 byte aligned notes?
> 
> NT_GNU_PROPERTY_TYPE_0 can have 64-bit integer properties
> in 64-bit objects.  They should be aligned to 8 bytes.

Not necessarily. You can have not naturally aligned data in files. ELF
files are cross architectures, so you have to account for different
alignments and endian issues anyway. Is there a specific property of
these 64-bit integers that require them to be 8 byte aligned in the
note descriptor data?

Thanks,

Mark

Re: What integer type should ELF note header have?

[H.J. Lu]

On Thu, Dec 14, 2017 at 2:06 AM, Mark Wielaard <mark@klomp.org> wrote:
> On Wed, 2017-12-13 at 10:09 -0800, H.J. Lu wrote:
>> On Wed, Dec 13, 2017 at 5:57 AM, Mark Wielaard <mark@klomp.org>
>> wrote:
>> > On Mon, 2017-12-11 at 04:11 -0800, H.J. Lu wrote:
>> > > Note segments/sections with 8 byte alignment should use Elf64_Nhdr64.
>> > > If we want to do it, we should do it now before
>> > > NT_GNU_PROPERTY_TYPE_0
>> > > notes with the existing Elf64_Nhdr are generated by GCC 8 with
>> > > -fcf-protection -mcet.
>> >
>> > Yes, I think having a new note type is the way to go, if we want to
>> > change the alignment requirements.
>> >
>> > BTW. What is the reason you need 8 byte aligned notes?
>>
>> NT_GNU_PROPERTY_TYPE_0 can have 64-bit integer properties
>> in 64-bit objects.  They should be aligned to 8 bytes.
>
> Not necessarily. You can have not naturally aligned data in files. ELF
> files are cross architectures, so you have to account for different

64-bit integers in NT_GNU_PROPERTY_TYPE_0 note are naturally aligned
by design so that int64 can be used to access 64-bit integers in
NT_GNU_PROPERTY_TYPE_0 note on all architectures.

> alignments and endian issues anyway. Is there a specific property of
> these 64-bit integers that require them to be 8 byte aligned in the
> note descriptor data?

Currently it has GNU_PROPERTY_STACK_SIZE as 64-bit integer
in 64-bit objects.  We may add more in the future.


-- 
H.J.

Re: What integer type should ELF note header have?

[Mark Wielaard]

On Thu, 2017-12-14 at 08:39 -0800, H.J. Lu wrote:
> > > > BTW. What is the reason you need 8 byte aligned notes?
> > > 
> > > NT_GNU_PROPERTY_TYPE_0 can have 64-bit integer properties
> > > in 64-bit objects.  They should be aligned to 8 bytes.
> > 
> > Not necessarily. You can have not naturally aligned data in files.
> > ELF
> > files are cross architectures, so you have to account for different
> 
> 64-bit integers in NT_GNU_PROPERTY_TYPE_0 note are naturally aligned
> by design so that int64 can be used to access 64-bit integers in
> NT_GNU_PROPERTY_TYPE_0 note on all architectures.
> 
> > alignments and endian issues anyway. Is there a specific property
> > of
> > these 64-bit integers that require them to be 8 byte aligned in the
> > note descriptor data?
> 
> Currently it has GNU_PROPERTY_STACK_SIZE as 64-bit integer
> in 64-bit objects.  We may add more in the future.

So is it just convenience, so you don't have to write a
read_8byte_unaligned_value macro to read the data in the note?

I sympathize that reading note data can be a bit of a pain because you
cannot rely on the data being naturally aligned. But I am unsure that
is such a big trouble that it needs new alignment/layout rules.

Cheers,

Mark

Re: What integer type should ELF note header have?

[H.J. Lu]

On Fri, Dec 15, 2017 at 7:38 AM, Mark Wielaard <mark@klomp.org> wrote:
> On Thu, 2017-12-14 at 08:39 -0800, H.J. Lu wrote:
>> > > > BTW. What is the reason you need 8 byte aligned notes?
>> > >
>> > > NT_GNU_PROPERTY_TYPE_0 can have 64-bit integer properties
>> > > in 64-bit objects.  They should be aligned to 8 bytes.
>> >
>> > Not necessarily. You can have not naturally aligned data in files.
>> > ELF
>> > files are cross architectures, so you have to account for different
>>
>> 64-bit integers in NT_GNU_PROPERTY_TYPE_0 note are naturally aligned
>> by design so that int64 can be used to access 64-bit integers in
>> NT_GNU_PROPERTY_TYPE_0 note on all architectures.
>>
>> > alignments and endian issues anyway. Is there a specific property
>> > of
>> > these 64-bit integers that require them to be 8 byte aligned in the
>> > note descriptor data?
>>
>> Currently it has GNU_PROPERTY_STACK_SIZE as 64-bit integer
>> in 64-bit objects.  We may add more in the future.
>
> So is it just convenience, so you don't have to write a
> read_8byte_unaligned_value macro to read the data in the note?
>
> I sympathize that reading note data can be a bit of a pain because you
> cannot rely on the data being naturally aligned. But I am unsure that
> is such a big trouble that it needs new alignment/layout rules.
>

One of NT_GNU_PROPERTY_TYPE_0 note consumers is program
loader.  I believe 64-bit integers in NT_GNU_PROPERTY_TYPE_0 note
should be naturally aligned.

H.J.

Re: What integer type should ELF note header have?

[Mark Wielaard]

On Fri, 2017-12-15 at 08:52 -0800, H.J. Lu wrote:
> > On Fri, Dec 15, 2017 at 8:37 AM, Mark Wielaard <mark@klomp.org> wrote:
> > But honestly it feels much cleaner to just leave this past mistake be.
> > And maybe just introduce new notes types if people really care about
> > having naturally aligned note data in 64-bit ELF files.
> 
> If NT_GNU_PROPERTY_TYPE_0 note is the only concern, I have
> updated all of its REAL consumers to handle it properly.  It is OK if a tool
> doesn't understand it.

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.

> However, if we want to add SHT_NOTE64/PT_NOTE64, please do it ASAP
> since NT_GNU_PROPERTY_TYPE_0 note is used for Intel CET.

Yes, I think that is the correct long term solution. But we might not
get consensus soon over the holiday season. So if you probably should
do something that doesn't require introducing new note layout/alignment
or new note section/phdr 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.

If you insist on having the data value be naturally aligned for this
one property then it might make sense to look if you can use an
existing ELF construct that does give those guarantees. e.g. Use a
special symbol, PT header or DT value to encode the property.

Cheers,

Mark

Re: What integer type should ELF note header have?

[Mark Wielaard]

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

Re: What integer type should ELF note header have?

[Ali Bahrami]

On 12/10/17 12:52, Suprateeka R Hegde wrote:
> This is the reason why on HP-UX we do not even have that
> Elf[64|32]_Nhdr. It would make the word size same for both 32-bit and
> 64-bit data models. I think even gABI does not define *_Nhdr. Or am I
> mistaken?

    I think you're right, these aren't in the gABI, just in the libelf.h
header.

Of course, the header is expected to reflect the gABI, and it's easy to
see how the header would be persuasive documentation to anyone trying to
work out what the gABI intends. It's somewhat less than gABI, and somewhat
more than "some guy on google says". :-)

- Ali