GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections

GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections

[H.J. Lu]

According to gABI, each note entry should be aligned to 4 bytes in 32-bit
objects or 8 bytes in 64-bit objects.  But Linux has been using 4 byte 
alignment for .note.ABI-tag note and .note.gnu.build-id note in 64-bit
objects.  We can't change their alignment to 8 bytes.  Since all notes i
n one PT_LOAD segment must have the same alignment which equals to p_align.
Note parser can use p_align of PT_LOAD segment for note alignment, instead
of assuming alignment based on ELF file class.

Here is a patch to Linux Extensions to gABI.  I also regenerated PDF
file at

https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI

H.J.
---
Document difference in alignment of .note.ABI-tag and .note.gnu.build-id
sections from gABI.
---
 object-files.tex | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/object-files.tex b/object-files.tex
index 64ce243..5b7b414 100644
--- a/object-files.tex
+++ b/object-files.tex
@@ -518,6 +518,18 @@ identify OS and version targeted.  It can be merged with other
    signifies a 2.2.5 kernel.
 \end{description}
 
+\subsection{Alignment of Note Sections}
+
+All entries in a \texttt{PT_LOAD} segment have the same alignment which
+equals to the {\tt 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 \code{.note.ABI-tag}
+section (see Section~\ref{sec_abi_tag}) and \code{.note.gnu.build-id}
+section (see Section~\ref{sec_build_id}) are aligned to 4 bytes in
+both 32-bit and 64-bit objects.  Note parser should use {\tt p_align}
+for note alignment, instead of assuming alignment based on ELF file class.
+
 \section{Symbol Table}
 
 \begin{table}[H]
-- 
2.14.3

Re: GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

On Fri, Nov 17, 2017 at 5:59 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> According to gABI, each note entry should be aligned to 4 bytes in 32-bit
> objects or 8 bytes in 64-bit objects.  But Linux has been using 4 byte
> alignment for .note.ABI-tag note and .note.gnu.build-id note in 64-bit
> objects.  We can't change their alignment to 8 bytes.  Since all notes i
> n one PT_LOAD segment must have the same alignment which equals to p_align.
> Note parser can use p_align of PT_LOAD segment for note alignment, instead
> of assuming alignment based on ELF file class.
>
> Here is a patch to Linux Extensions to gABI.  I also regenerated PDF
> file at
>
> https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI
>
> H.J.
> ---
> Document difference in alignment of .note.ABI-tag and .note.gnu.build-id
> sections from gABI.
> ---
>  object-files.tex | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/object-files.tex b/object-files.tex
> index 64ce243..5b7b414 100644
> --- a/object-files.tex
> +++ b/object-files.tex
> @@ -518,6 +518,18 @@ identify OS and version targeted.  It can be merged with other
>     signifies a 2.2.5 kernel.
>  \end{description}
>
> +\subsection{Alignment of Note Sections}
> +
> +All entries in a \texttt{PT_LOAD} segment have the same alignment which
                                     ^^^^^^^^^^^^^ Typo.  It should PT_NOTE.
> +equals to the {\tt 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 \code{.note.ABI-tag}
> +section (see Section~\ref{sec_abi_tag}) and \code{.note.gnu.build-id}
> +section (see Section~\ref{sec_build_id}) are aligned to 4 bytes in
> +both 32-bit and 64-bit objects.  Note parser should use {\tt p_align}
> +for note alignment, instead of assuming alignment based on ELF file class.
> +
>  \section{Symbol Table}
>
>  \begin{table}[H]

Here is the updated patch.


-- 
H.J.

[-- Attachment #2: 0001-Add-a-section-for-alignment-of-note-sections.patch --]
[-- Type: text/x-patch, Size: 1294 bytes --]

From 9a7bc47bf065405c2e7b6c46d692a7d137d5f544 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 17 Nov 2017 05:41:09 -0800
Subject: [PATCH] Add a section for alignment of note sections

Document difference in alignment of .note.ABI-tag and .note.gnu.build-id
sections from gABI.
---
 object-files.tex | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/object-files.tex b/object-files.tex
index 64ce243..c33965d 100644
--- a/object-files.tex
+++ b/object-files.tex
@@ -518,6 +518,18 @@ identify OS and version targeted.  It can be merged with other
    signifies a 2.2.5 kernel.
 \end{description}
 
+\subsection{Alignment of Note Sections}
+
+All entries in a \texttt{PT_NOTE} segment have the same alignment which
+equals to the {\tt 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 \code{.note.ABI-tag}
+section (see Section~\ref{sec_abi_tag}) and \code{.note.gnu.build-id}
+section (see Section~\ref{sec_build_id}) are aligned to 4 bytes in
+both 32-bit and 64-bit objects.  Note parser should use {\tt p_align}
+for note alignment, instead of assuming alignment based on ELF file class.
+
 \section{Symbol Table}
 
 \begin{table}[H]
-- 
2.14.3

Re: GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections

[Mark Mentovai]

I think that this recent change (commit 9a7bc47bf065) misses the
larger point. The alignment isn’t the only thing at issue here, the
very definition of the ELF note section is.

Quoting http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section:

> In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each
> entry is an array of 8-byte words in the format of the target processor. In
> 32-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS32), each entry
> is an array of 4-byte words in the format of the target processor.

This is not followed by ELF on Linux (or, in fact, most other
systems), which define the note structure for 32-bit and 64-bit ELF
objects identically, as arrays of 4-byte words:

typedef uint32_t Elf32_Word;
typedef uint32_t Elf64_Word;
typedef struct {
  Elf32_Word n_namesz;
  Elf32_Word n_descsz;
  Elf32_Word n_type;
} Elf32_Nhdr;
typedef struct {
  Elf64_Word n_namesz;
  Elf64_Word n_descsz;
  Elf64_Word n_type;
} Elf64_Nhdr;

The requirement to use different note structures for 32-bit and 64-bit
objects is present in the 1998-04-29 gABI draft at earliest
(http://www.sco.com/developers/gabi/1998-04-29/ch5.pheader.html#note_section),
but is absent from Edition 4.1
(http://www.sco.com/developers/devspecs/gabi41.pdf#page=81), prior to
the standardization of the 64-bit format.

This structure’s alignment naturally follows its definition, and
specifically the sizes of the types involved.

As Linux deviates from the gABI in this not-insignificant way, the
Linux Extensions document ought to codify the distinction. The ELF
note structure definitions have been baked into too many places for
too much time to reasonably expect them to change.

Because Linux isn’t the only system to define the note structure in
this way even for 64-bit objects, it may be worth a mention in the
gABI as well, although I don’t know how to communicate this to its
maintainers.