This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold

On 08/16/2018 03:19 PM, H.J. Lu wrote:
On Thu, Aug 16, 2018 at 6:00 AM, Florian Weimer <> wrote:
On 08/07/2018 10:41 PM, H.J. Lu wrote:

The section with NT_GNU_PROPERTY_TYPE_0 has been
added to Linux Extensions to gABI:

processor-specific program property types for i386 and x86-64.

The specification is incomplete as far as alignment matters are concerned.


2.1.7 Alignment of Note Sections

All entries in a PT_NOTE segment have the same alignment which equals to the
p_align field in program header.
According to gABI, each note entry should be aligned to 4 bytes in 32-bit
objects or 8 bytes in 64-bit objects. But .note.ABI-tag section (see
Section 2.1.6) and section (see Section 2.1.4) are
to 4 bytes in both 32-bit and 64-bit objects. Note parser should use p_align for
note alignment, instead of assuming alignment based on ELF file class.

This is still ambiguous, particularly based on your comments below.

Is the link editor supposed to maintain separate segments for notes with
different alignments?  Or is it possible to merge the notes into a single
segment, potentially after adjusting alignment?

It is possible.  We just need to place 4-byte aligned notes after 8-byte
aligned notes.

Based on section 2.1.7, this would not be valid by itself because the section needs to have 8-byte alignment (to satisfy the property notes requirement). All notes in the segment need to have the same alignment (because p_align is supposed to be used for parsing). So reordering alone will not produce a valid segment.

Part of the problem is that the note header is 12 bytes (not a multiple of 8), and that the name and descriptor lengths do not include the padding (which makes sense), so you really need a correct source of alignment.

If we want to generate a single segment (and I think we should), we need to realign the notes to a common alignment, either 4 or 8 bytes. That's what gold seems todo right now, with 4-byte alignment.

Is the link editor *required* to produce 8-byte alignment for notes in
ELFCLASS64 objects?

It is decided by the alignment of NOTE section, not by linker.

Currently, we do not have agreement between binutils (particularly gold) and
the glibc dynamic loader when it comes to alignment of PT_NOTE segments.
glibc will disregard property notes in ELFCLASS64 objects which have 4-byte
alignment, but gold produces such notes.  This needs to be fixed.

I don't believe this is true.  See above.

Which part? I see the 4-byte segment alignment with gold from binutils-2.31.1-11.fc29.x86_64.

After this commit:

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

     Properly compute offsets of note descriptor and next note [BZ #22370]
glibc can handle both 4 byte and 8 byte NOTE alignments.

There's still this code in glibc, in sysdeps/x86/dl-prop.h:

  /* The NT_GNU_PROPERTY_TYPE_0 note must be aliged to 4 bytes in
     32-bit objects and to 8 bytes in 64-bit objects.  Skip notes
     with incorrect alignment.  */
  if (align != (__ELF_NATIVE_CLASS / 8))


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]