This is the mail archive of the
mailing list for the glibc project.
Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold (was: Re: [PATCH] Document GNU_PROPERTY_X86_ISA_1_[USED|NEEDED])
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: x86-64-abi <x86-64-abi at googlegroups dot com>, Binutils <binutils at sourceware dot org>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 16 Aug 2018 06:19:33 -0700
- Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold (was: Re: [PATCH] Document GNU_PROPERTY_X86_ISA_1_[USED|NEEDED])
- References: <CAMe9rOrrayKnc_cPm4SmnDnUGLbBUmOYMBTMOM8KLAHVmb=rUQ@mail.gmail.com> <firstname.lastname@example.org>
On Thu, Aug 16, 2018 at 6:00 AM, Florian Weimer <email@example.com> wrote:
> On 08/07/2018 10:41 PM, H.J. Lu wrote:
>> The .note.gnu.property section with NT_GNU_PROPERTY_TYPE_0 has been
>> added to Linux Extensions to gABI:
>> GNU_PROPERTY_X86_ISA_1_USED and GNU_PROPERTY_X86_ISA_1_NEEDED are
>> 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 .note.gnu.build-id 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.
> 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
> 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.
After this commit:
Author: H.J. Lu <firstname.lastname@example.org>
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.
glibc can handle both 4 byte and 8 byte NOTE alignments.