RFC: Program Properties

RFC: Program Properties

[H.J. Lu]

There are cases where linker and run-time loader need more information
about ELF objects beyond what the current gABI provides:

1. Minimum ISAs.  Executables and shared objects, which are optimized
specifically to run on a particular processor, will not run on processors
which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
information to tell if an executable or a shared object is compatible
with available ISAs.
2. Stack size.  Compilers may generate binaries which require larger stack
size than normal.  If run-time loader can query the stack size required
by executable or shared object, it can increase stack size as needed.
3. Additional linking command line options embedded in relocatable object
files:
   a. Additional libraries should be linked in when creating executable
      or shared object.
      http://sourceware.org/bugzilla/show_bug.cgi?id=12485
   b. Additional compiler command line options are needed to properly
      link LTO objects.
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
4. Relocatable object files compiled against header files from a specific
version of a library must be linked with a compatible library when
creating executable or shared object.

GNU attributes

GNU binutils supports build attribute and run-time platform compatibility
data in relocatable object files.  Issues with GNU attributes:

1. Many architectures, including x86, don't support GNU attributes:
   a. There are some overlaps between GNU attributes and program
   properties.
   b. GNU attributes may be extended to embed additional linking command
   line options in relocatable object files.
2. On x86, linking a relocatable object full of AVX instructions doesn't
always make the resulting executables or shared libraries to require AVX
to run since AVX functions may be called only via GNU_IFUNC at run-time.
Linker can't set minimum ISAs just from ISAs used by input relocatable
objects.
3. There is no program segment for GNU attributes in executables and
shared objects.
4. Most of attributes aren't applicable to run-time loader.
5. The format of GNU attributes isn't optimal for run-time loader.  A
separate string table is used to store string attributes.

gABI support for program properties

To the "Special Sections" section, add:

     Name                Type                 Attributes
.note.GNU-properties    SHT_NOTE        SHF_ALLOC+SHF_GNU_PROPERTIES

#define SHF_GNU_PROPERTIES              0x00100000

Each SHF_GNU_PROPERTIES section starts with a property header and
followed by an array of properties.  The property header has the following
structure:

typedef struct {
  Elf_Word ph_kind;
  unsigned char ph_padding[PH_PADDING];
  Elf_SizeWord ph_propsz;
} Elf_Prophdr;

where ph_kind specifies the property kind:

#define NT_GNU_PROPERTIES_HEADER_KIND   0x0

and PH_PADDING, if necessary, aligns ph_propsz to 8 or 4-byte alignment
(depending on whether the file is a 64-bit or 32-bit object).  Elf_SizeWord
is Elf32_Word in the 32-bit object or Elf64_Xword in the 64-bit object.
ph_propsz contains the size of the property array.  Each array element
represents one property with type, data size and data.  In 64-bit objects,
each element is an array of 8-byte words, whose first element is 4-byte
type and data size, in the format of the target processor.  In 32-bit
objects, each element is an array of 4-byte words, whose first 2 elements
are 4-byte type and data size, in the format of the target processor.  An
array element has the following structure:

typedef struct {
  Elf_Word pr_type;
  Elf_Word pr_datasz
  unsigned char pr_data[PR_DATASZ];
  unsigned char pr_padding[PR_PADDING];
} Elf_Prop;

where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
array element to 8 or 4-byte alignment (depending on whether the file
is a 64-bit or 32-bit object).  The array elements are sorted by the
property type.  The interpretation of property array depends on both
ph_kind and pr_type.

Types of program properties

#define NT_GNU_PROPERTIES_LOPROC        0xb0000000
#define NT_GNU_PROPERTIES_HIPROC        0xdfffffff
#define NT_GNU_PROPERTIES_LOUSER        0xe0000000
#define NT_GNU_PROPERTIES_HIUSER        0xffffffff

To the "Program Header" section, add a segment type PT_GNU_PROPERTIES

#define PT_GNU_PROPERTIES               (PT_LOOS + 0x474e556)

Program header should contain only one PT_GNU_PROPERTIES segment, which
contains at least one .note.GNU-properties section.

Proposed properties

For NT_GNU_PROPERTIES_HEADER_KIND == 0:

#define NT_GNU_PROPERTIES_STACK_SIZE              1

Integer value for minimum stack size.

#define NT_GNU_PROPERTIES_REQUIRED_LIBRARY        2

String of the required library, NAMESPEC:SONAME.  NAMESPEC is the string
after the linker -l option.  SONAME is DT_SONAME of the required library.

#define NT_GNU_PROPERTIES_PROVIDED_LIBRARY        3

String of the provided library, NAMESPEC:SONAME.  NAMESPEC is the string
after the linker -l option.  SONAME is DT_SONAME of the provided library.

There is a conflict in linker inputs if

1. Any NT_GNU_PROPERTIES_REQUIRED_LIBRARY or
NT_GNU_PROPERTIES_PROVIDED_LIBRARY have the same NAMESPEC, but different
SONAMEs.
2. NAMESPEC in any NT_GNU_PROPERTIES_REQUIRED_LIBRARY matches an input
libNAMESPEC.so whose DT_SONAME is different from SONAME.

#define NT_GNU_PROPERTIES_GCC_OPTIONS             4

GCC options must be passed to GCC when used with GCC.

#define NT_GNU_PROPERTIES_X86_ISA_1_USED          0xc0000000

The x86 instruction sets indicated by the corresponding bits are used
in program.  But their support in the hardware is optional.

#define NT_GNU_PROPERTIES_X86_ISA_1_NEEDED        0xc0000001

The x86 instruction sets indicated by the corresponding bits are used
in program and they must be supported by the hardware.  A bit set in
NT_GNU_PROPERTIES_X86_ISA_1_NEEDED must also be set in
NT_GNU_PROPERTIES_X86_ISA_1_USED.

Integer value for the x86 instruction set support.

#define NT_GNU_PROPERTIES_X86_ISA_1_486           (1U << 0)
#define NT_GNU_PROPERTIES_X86_ISA_1_586           (1U << 1)
#define NT_GNU_PROPERTIES_X86_ISA_1_686           (1U << 2)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE           (1U << 3)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE2          (1U << 4)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE3          (1U << 5)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSSE3         (1U << 6)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE4_1        (1U << 7)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE4_2        (1U << 8)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX           (1U << 9)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX2          (1U << 10)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512F       (1U << 11)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512CD      (1U << 12)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512ER      (1U << 13)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512PF      (1U << 14)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512VL      (1U << 15)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512DQ      (1U << 16)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512BW      (1U << 17)

Re: RFC: Program Properties

[H.J. Lu]

Here is the updated proposal.  The main changes are

1. Remove SHF_GNU_PROPERTIES and PT_GNU_PROPERTIES.
2. Add NT_GNU_PROPERTIES_NO_COPY_ON_PROTECTED to
prevent copy relocation against protected data symbol.


H.J.
---
Program Properties

There are cases where linker and run-time loader need more information
about ELF objects beyond what the current gABI provides:

1. Minimum ISAs.  Executables and shared objects, which are optimized
specifically to run on a particular processor, will not run on processors
which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
information to tell if an executable or a shared object is compatible
with available ISAs.
2. Stack size.  Compilers may generate binaries which require larger stack
size than normal.  If run-time loader can query the stack size required
by executable or shared object, it can increase stack size as needed.
3. Additional linking command line options embedded in relocatable object
files:
   a. Additional libraries should be linked in when creating executable
      or shared object.
      http://sourceware.org/bugzilla/show_bug.cgi?id=12485
   b. Additional compiler command line options are needed to properly
      link LTO objects.
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
4. Relocatable object files compiled against header files from a specific
version of a library must be linked with a compatible library when
creating executable or shared object.
5. Copy relocation and protected visibility are fundamentally incompatible.
On on hand, copy relocation is the part of the psABI and is used to
access global data defined in a shared object from the executable.  It
moves the definition of global data, which is defined in a share object,
to the executable at run-time.  On the other hand, protected visibility
indicates that a symbol is defined locally in the shared object at
run-time.  Both can't be true at the same time.  The current solution
is to make protected symbol more or less like normal symbol, which
prevents optimizing local access to protected symbol within the shared
object.

GNU attributes

GNU binutils supports build attribute and run-time platform compatibility
data in relocatable object files.  Issues with GNU attributes:

1. Many architectures, including x86, don't support GNU attributes:
   a. There are some overlaps between GNU attributes and program
   properties.
   b. GNU attributes may be extended to embed additional linking command
   line options in relocatable object files.
2. On x86, linking a relocatable object full of AVX instructions doesn't
always make the resulting executables or shared libraries to require AVX
to run since AVX functions may be called only via GNU_IFUNC at run-time.
Linker can't set minimum ISAs just from ISAs used by input relocatable
objects.
3. There is no program segment for GNU attributes in executables and
shared objects.
4. Most of attributes aren't applicable to run-time loader.
5. The format of GNU attributes isn't optimal for run-time loader.  A
separate string table is used to store string attributes.

gABI support for program properties

To the "Special Sections" section, add:

     Name                Type                 Attributes
.note.GNU-properties    SHT_NOTE              SHF_ALLOC

A .note.GNU-properties section contains a property note descriptor,
starting with a property note descriptor header and followed by an array
of properties.  It can be merged with other SHT_NOTE sections.  The
property note descriptor header has the following structure:

typedef struct {
  Elf_Word namsz;
  Elf_Word descsz;
  Elf_Word type;
  unsigned char name[4];
} Elf_GNU_Notehdr;

1. namesz is 4.
2. descsz contains the size of the property array.
3. type specifies the property type:

#define NT_GNU_PROPERTIES_TYPE_0   5

4. name is a null-terminated character string. It should be "GNU".

Each array element represents one property with type, data size and data.
In 64-bit objects, each element is an array of 8-byte words, whose first
element is 4-byte type and data size, in the format of the target processor.
In 32-bit objects, each element is an array of 4-byte words, whose first 2
elements are 4-byte type and data size, in the format of the target
processor.  An array element has the following structure:

typedef struct {
  Elf_Word pr_type;
  Elf_Word pr_datasz
  unsigned char pr_data[PR_DATASZ];
  unsigned char pr_padding[PR_PADDING];
} Elf_Prop;

where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
array element to 8 or 4-byte alignment (depending on whether the file
is a 64-bit or 32-bit object).  The array elements are sorted by the
property type.  The interpretation of property array depends on both
ph_kind and pr_type.

Types of program properties

#define NT_GNU_PROPERTIES_LOPROC        0xb0000000
#define NT_GNU_PROPERTIES_HIPROC        0xdfffffff
#define NT_GNU_PROPERTIES_LOUSER        0xe0000000
#define NT_GNU_PROPERTIES_HIUSER        0xffffffff

Proposed properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
gnu-6:pts/11[293]> cat properties.txt         /export/gnu/import/git/properties
Program Properties

There are cases where linker and run-time loader need more information
about ELF objects beyond what the current gABI provides:

1. Minimum ISAs.  Executables and shared objects, which are optimized
specifically to run on a particular processor, will not run on processors
which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
information to tell if an executable or a shared object is compatible
with available ISAs.
2. Stack size.  Compilers may generate binaries which require larger stack
size than normal.  If run-time loader can query the stack size required
by executable or shared object, it can increase stack size as needed.
3. Additional linking command line options embedded in relocatable object
files:
   a. Additional libraries should be linked in when creating executable
      or shared object.
      http://sourceware.org/bugzilla/show_bug.cgi?id=12485
   b. Additional compiler command line options are needed to properly
      link LTO objects.
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
4. Relocatable object files compiled against header files from a specific
version of a library must be linked with a compatible library when
creating executable or shared object.
5. Copy relocation and protected visibility are fundamentally incompatible.
On on hand, copy relocation is the part of the psABI and is used to
access global data defined in a shared object from the executable.  It
moves the definition of global data, which is defined in a share object,
to the executable at run-time.  On the other hand, protected visibility
indicates that a symbol is defined locally in the shared object at
run-time.  Both can't be true at the same time.  The current solution
is to make protected symbol more or less like normal symbol, which
prevents optimizing local access to protected symbol within the shared
object.

GNU attributes

GNU binutils supports build attribute and run-time platform compatibility
data in relocatable object files.  Issues with GNU attributes:

1. Many architectures, including x86, don't support GNU attributes:
   a. There are some overlaps between GNU attributes and program
   properties.
   b. GNU attributes may be extended to embed additional linking command
   line options in relocatable object files.
2. On x86, linking a relocatable object full of AVX instructions doesn't
always make the resulting executables or shared libraries to require AVX
to run since AVX functions may be called only via GNU_IFUNC at run-time.
Linker can't set minimum ISAs just from ISAs used by input relocatable
objects.
3. There is no program segment for GNU attributes in executables and
shared objects.
4. Most of attributes aren't applicable to run-time loader.
5. The format of GNU attributes isn't optimal for run-time loader.  A
separate string table is used to store string attributes.

gABI support for program properties

To the "Special Sections" section, add:

     Name                Type                 Attributes
.note.GNU-properties    SHT_NOTE              SHF_ALLOC

A .note.GNU-properties section contains a property note descriptor,
starting with a property note descriptor header and followed by an array
of properties.  It can be merged with other SHT_NOTE sections.  The
property note descriptor header has the following structure:

typedef struct {
  Elf_Word namsz;
  Elf_Word descsz;
  Elf_Word type;
  unsigned char name[4];
} Elf_GNU_Notehdr;

1. namesz is 4.
2. descsz contains the size of the property array.
3. type specifies the property type:

#define NT_GNU_PROPERTIES_TYPE_0   5

4. name is a null-terminated character string. It should be "GNU".

Each array element represents one property with type, data size and data.
In 64-bit objects, each element is an array of 8-byte words, whose first
element is 4-byte type and data size, in the format of the target processor.
In 32-bit objects, each element is an array of 4-byte words, whose first 2
elements are 4-byte type and data size, in the format of the target
processor.  An array element has the following structure:

typedef struct {
  Elf_Word pr_type;
  Elf_Word pr_datasz
  unsigned char pr_data[PR_DATASZ];
  unsigned char pr_padding[PR_PADDING];
} Elf_Prop;

where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
array element to 8 or 4-byte alignment (depending on whether the file
is a 64-bit or 32-bit object).  The array elements are sorted by the
property type.  The interpretation of property array depends on both
ph_kind and pr_type.

Types of program properties

#define NT_GNU_PROPERTIES_LOPROC        0xb0000000
#define NT_GNU_PROPERTIES_HIPROC        0xdfffffff
#define NT_GNU_PROPERTIES_LOUSER        0xe0000000
#define NT_GNU_PROPERTIES_HIUSER        0xffffffff

Proposed properties

For NT_GNU_PROPERTIES_TYPE_0:

#define NT_GNU_PROPERTIES_STACK_SIZE              1

Integer value for minimum stack size.

#define NT_GNU_PROPERTIES_REQUIRED_LIBRARY        2

String of the required library, NAMESPEC:SONAME.  NAMESPEC is the string
after the linker -l option.  SONAME is DT_SONAME of the required library.

#define NT_GNU_PROPERTIES_PROVIDED_LIBRARY        3

String of the provided library, NAMESPEC:SONAME.  NAMESPEC is the string
after the linker -l option.  SONAME is DT_SONAME of the provided library.

There is a conflict in linker inputs if

1. Any NT_GNU_PROPERTIES_REQUIRED_LIBRARY or
NT_GNU_PROPERTIES_PROVIDED_LIBRARY have the same NAMESPEC, but different
SONAMEs.
2. NAMESPEC in any NT_GNU_PROPERTIES_REQUIRED_LIBRARY matches an input
libNAMESPEC.so whose DT_SONAME is different from SONAME.

#define NT_GNU_PROPERTIES_GCC_OPTIONS             4

GCC options must be passed to GCC when used with GCC.

#define NT_GNU_PROPERTIES_NO_COPY_ON_PROTECTED    5

This indicates that there should be no copy relocations against protected
data symbols.  If a relocatable object contains this property, linker
should treat protected data symbol as defined locally at run-time and copy
this property to the output share object.  Run-time loader should disallow
copy relocations against protected data symbols defined in share objects
with NT_GNU_PROPERTIES_NO_COPY_ON_PROTECTED property.

#define NT_GNU_PROPERTIES_X86_ISA_1_USED          0xc0000000

The x86 instruction sets indicated by the corresponding bits are used
in program.  But their support in the hardware is optional.

#define NT_GNU_PROPERTIES_X86_ISA_1_NEEDED        0xc0000001

The x86 instruction sets indicated by the corresponding bits are used
in program and they must be supported by the hardware.  A bit set in
NT_GNU_PROPERTIES_X86_ISA_1_NEEDED must also be set in
NT_GNU_PROPERTIES_X86_ISA_1_USED.

Integer value for the x86 instruction set support.

#define NT_GNU_PROPERTIES_X86_ISA_1_486           (1U << 0)
#define NT_GNU_PROPERTIES_X86_ISA_1_586           (1U << 1)
#define NT_GNU_PROPERTIES_X86_ISA_1_686           (1U << 2)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE           (1U << 3)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE2          (1U << 4)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE3          (1U << 5)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSSE3         (1U << 6)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE4_1        (1U << 7)
#define NT_GNU_PROPERTIES_X86_ISA_1_SSE4_2        (1U << 8)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX           (1U << 9)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX2          (1U << 10)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512F       (1U << 11)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512CD      (1U << 12)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512ER      (1U << 13)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512PF      (1U << 14)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512VL      (1U << 15)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512DQ      (1U << 16)
#define NT_GNU_PROPERTIES_X86_ISA_1_AVX512BW      (1U << 17)

Re: RFC: Program Properties

[Suprateeka R Hegde]

H.J,

IMHO, this looks too huge to apprehend in one discussion. Would you 
consider:

1. Splitting into multiple (at least 3) logical groups based on use cases?
2. If possible, a one-liner problem statement or inefficiencies in the 
existing gABI or GNU extensions?

(Just trying to streamline and avoid a turbulent discussion)

--
Supra



On 31-Mar-2016 08:32 PM, H.J. Lu wrote:
> Here is the updated proposal.  The main changes are
>
> 1. Remove SHF_GNU_PROPERTIES and PT_GNU_PROPERTIES.
> 2. Add NT_GNU_PROPERTIES_NO_COPY_ON_PROTECTED to
> prevent copy relocation against protected data symbol.
>
>
> H.J.
> ---
> Program Properties
>
> There are cases where linker and run-time loader need more information
> about ELF objects beyond what the current gABI provides:
>
> 1. Minimum ISAs.  Executables and shared objects, which are optimized
> specifically to run on a particular processor, will not run on processors
> which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
> EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
> information to tell if an executable or a shared object is compatible
> with available ISAs.
> 2. Stack size.  Compilers may generate binaries which require larger stack
> size than normal.  If run-time loader can query the stack size required
> by executable or shared object, it can increase stack size as needed.
> 3. Additional linking command line options embedded in relocatable object
> files:
>     a. Additional libraries should be linked in when creating executable
>        or shared object.
>        http://sourceware.org/bugzilla/show_bug.cgi?id=12485
>     b. Additional compiler command line options are needed to properly
>        link LTO objects.
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
> 4. Relocatable object files compiled against header files from a specific
> version of a library must be linked with a compatible library when
> creating executable or shared object.
> 5. Copy relocation and protected visibility are fundamentally incompatible.
> On on hand, copy relocation is the part of the psABI and is used to
> access global data defined in a shared object from the executable.  It
> moves the definition of global data, which is defined in a share object,
> to the executable at run-time.  On the other hand, protected visibility
> indicates that a symbol is defined locally in the shared object at
> run-time.  Both can't be true at the same time.  The current solution
> is to make protected symbol more or less like normal symbol, which
> prevents optimizing local access to protected symbol within the shared
> object.
>
> GNU attributes
>
> GNU binutils supports build attribute and run-time platform compatibility
> data in relocatable object files.  Issues with GNU attributes:
>
> 1. Many architectures, including x86, don't support GNU attributes:
>     a. There are some overlaps between GNU attributes and program
>     properties.
>     b. GNU attributes may be extended to embed additional linking command
>     line options in relocatable object files.
> 2. On x86, linking a relocatable object full of AVX instructions doesn't
> always make the resulting executables or shared libraries to require AVX
> to run since AVX functions may be called only via GNU_IFUNC at run-time.
> Linker can't set minimum ISAs just from ISAs used by input relocatable
> objects.
> 3. There is no program segment for GNU attributes in executables and
> shared objects.
> 4. Most of attributes aren't applicable to run-time loader.
> 5. The format of GNU attributes isn't optimal for run-time loader.  A
> separate string table is used to store string attributes.
>
> gABI support for program properties
>
> To the "Special Sections" section, add:
>
>       Name                Type                 Attributes
> .note.GNU-properties    SHT_NOTE              SHF_ALLOC
>
> A .note.GNU-properties section contains a property note descriptor,
> starting with a property note descriptor header and followed by an array
> of properties.  It can be merged with other SHT_NOTE sections.  The
> property note descriptor header has the following structure:
>
> typedef struct {
>    Elf_Word namsz;
>    Elf_Word descsz;
>    Elf_Word type;
>    unsigned char name[4];
> } Elf_GNU_Notehdr;
>
> 1. namesz is 4.
> 2. descsz contains the size of the property array.
> 3. type specifies the property type:
>
> #define NT_GNU_PROPERTIES_TYPE_0   5
>
> 4. name is a null-terminated character string. It should be "GNU".
>
> Each array element represents one property with type, data size and data.
> In 64-bit objects, each element is an array of 8-byte words, whose first
> element is 4-byte type and data size, in the format of the target processor.
> In 32-bit objects, each element is an array of 4-byte words, whose first 2
> elements are 4-byte type and data size, in the format of the target
> processor.  An array element has the following structure:
>
> typedef struct {
>    Elf_Word pr_type;
>    Elf_Word pr_datasz
>    unsigned char pr_data[PR_DATASZ];
>    unsigned char pr_padding[PR_PADDING];
> } Elf_Prop;
>
> where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
> array element to 8 or 4-byte alignment (depending on whether the file
> is a 64-bit or 32-bit object).  The array elements are sorted by the
> property type.  The interpretation of property array depends on both
> ph_kind and pr_type.
>
> Types of program properties
>
> #define NT_GNU_PROPERTIES_LOPROC        0xb0000000
> #define NT_GNU_PROPERTIES_HIPROC        0xdfffffff
> #define NT_GNU_PROPERTIES_LOUSER        0xe0000000
> #define NT_GNU_PROPERTIES_HIUSER        0xffffffff
>
> Proposed properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]>                            /export/gnu/import/git/properties
> gnu-6:pts/11[293]> cat properties.txt         /export/gnu/import/git/properties
> Program Properties
>
> There are cases where linker and run-time loader need more information
> about ELF objects beyond what the current gABI provides:
>
> 1. Minimum ISAs.  Executables and shared objects, which are optimized
> specifically to run on a particular processor, will not run on processors
> which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
> EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
> information to tell if an executable or a shared object is compatible
> with available ISAs.
> 2. Stack size.  Compilers may generate binaries which require larger stack
> size than normal.  If run-time loader can query the stack size required
> by executable or shared object, it can increase stack size as needed.
> 3. Additional linking command line options embedded in relocatable object
> files:
>     a. Additional libraries should be linked in when creating executable
>        or shared object.
>        http://sourceware.org/bugzilla/show_bug.cgi?id=12485
>     b. Additional compiler command line options are needed to properly
>        link LTO objects.
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54231
>        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53777
> 4. Relocatable object files compiled against header files from a specific
> version of a library must be linked with a compatible library when
> creating executable or shared object.
> 5. Copy relocation and protected visibility are fundamentally incompatible.
> On on hand, copy relocation is the part of the psABI and is used to
> access global data defined in a shared object from the executable.  It
> moves the definition of global data, which is defined in a share object,
> to the executable at run-time.  On the other hand, protected visibility
> indicates that a symbol is defined locally in the shared object at
> run-time.  Both can't be true at the same time.  The current solution
> is to make protected symbol more or less like normal symbol, which
> prevents optimizing local access to protected symbol within the shared
> object.
>
> GNU attributes
>
> GNU binutils supports build attribute and run-time platform compatibility
> data in relocatable object files.  Issues with GNU attributes:
>
> 1. Many architectures, including x86, don't support GNU attributes:
>     a. There are some overlaps between GNU attributes and program
>     properties.
>     b. GNU attributes may be extended to embed additional linking command
>     line options in relocatable object files.
> 2. On x86, linking a relocatable object full of AVX instructions doesn't
> always make the resulting executables or shared libraries to require AVX
> to run since AVX functions may be called only via GNU_IFUNC at run-time.
> Linker can't set minimum ISAs just from ISAs used by input relocatable
> objects.
> 3. There is no program segment for GNU attributes in executables and
> shared objects.
> 4. Most of attributes aren't applicable to run-time loader.
> 5. The format of GNU attributes isn't optimal for run-time loader.  A
> separate string table is used to store string attributes.
>
> gABI support for program properties
>
> To the "Special Sections" section, add:
>
>       Name                Type                 Attributes
> .note.GNU-properties    SHT_NOTE              SHF_ALLOC
>
> A .note.GNU-properties section contains a property note descriptor,
> starting with a property note descriptor header and followed by an array
> of properties.  It can be merged with other SHT_NOTE sections.  The
> property note descriptor header has the following structure:
>
> typedef struct {
>    Elf_Word namsz;
>    Elf_Word descsz;
>    Elf_Word type;
>    unsigned char name[4];
> } Elf_GNU_Notehdr;
>
> 1. namesz is 4.
> 2. descsz contains the size of the property array.
> 3. type specifies the property type:
>
> #define NT_GNU_PROPERTIES_TYPE_0   5
>
> 4. name is a null-terminated character string. It should be "GNU".
>
> Each array element represents one property with type, data size and data.
> In 64-bit objects, each element is an array of 8-byte words, whose first
> element is 4-byte type and data size, in the format of the target processor.
> In 32-bit objects, each element is an array of 4-byte words, whose first 2
> elements are 4-byte type and data size, in the format of the target
> processor.  An array element has the following structure:
>
> typedef struct {
>    Elf_Word pr_type;
>    Elf_Word pr_datasz
>    unsigned char pr_data[PR_DATASZ];
>    unsigned char pr_padding[PR_PADDING];
> } Elf_Prop;
>
> where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
> array element to 8 or 4-byte alignment (depending on whether the file
> is a 64-bit or 32-bit object).  The array elements are sorted by the
> property type.  The interpretation of property array depends on both
> ph_kind and pr_type.
>
> Types of program properties
>
> #define NT_GNU_PROPERTIES_LOPROC        0xb0000000
> #define NT_GNU_PROPERTIES_HIPROC        0xdfffffff
> #define NT_GNU_PROPERTIES_LOUSER        0xe0000000
> #define NT_GNU_PROPERTIES_HIUSER        0xffffffff
>
> Proposed properties
>
> For NT_GNU_PROPERTIES_TYPE_0:
>
> #define NT_GNU_PROPERTIES_STACK_SIZE              1
>
> Integer value for minimum stack size.
>
> #define NT_GNU_PROPERTIES_REQUIRED_LIBRARY        2
>
> String of the required library, NAMESPEC:SONAME.  NAMESPEC is the string
> after the linker -l option.  SONAME is DT_SONAME of the required library.
>
> #define NT_GNU_PROPERTIES_PROVIDED_LIBRARY        3
>
> String of the provided library, NAMESPEC:SONAME.  NAMESPEC is the string
> after the linker -l option.  SONAME is DT_SONAME of the provided library.
>
> There is a conflict in linker inputs if
>
> 1. Any NT_GNU_PROPERTIES_REQUIRED_LIBRARY or
> NT_GNU_PROPERTIES_PROVIDED_LIBRARY have the same NAMESPEC, but different
> SONAMEs.
> 2. NAMESPEC in any NT_GNU_PROPERTIES_REQUIRED_LIBRARY matches an input
> libNAMESPEC.so whose DT_SONAME is different from SONAME.
>
> #define NT_GNU_PROPERTIES_GCC_OPTIONS             4
>
> GCC options must be passed to GCC when used with GCC.
>
> #define NT_GNU_PROPERTIES_NO_COPY_ON_PROTECTED    5
>
> This indicates that there should be no copy relocations against protected
> data symbols.  If a relocatable object contains this property, linker
> should treat protected data symbol as defined locally at run-time and copy
> this property to the output share object.  Run-time loader should disallow
> copy relocations against protected data symbols defined in share objects
> with NT_GNU_PROPERTIES_NO_COPY_ON_PROTECTED property.
>
> #define NT_GNU_PROPERTIES_X86_ISA_1_USED          0xc0000000
>
> The x86 instruction sets indicated by the corresponding bits are used
> in program.  But their support in the hardware is optional.
>
> #define NT_GNU_PROPERTIES_X86_ISA_1_NEEDED        0xc0000001
>
> The x86 instruction sets indicated by the corresponding bits are used
> in program and they must be supported by the hardware.  A bit set in
> NT_GNU_PROPERTIES_X86_ISA_1_NEEDED must also be set in
> NT_GNU_PROPERTIES_X86_ISA_1_USED.
>
> Integer value for the x86 instruction set support.
>
> #define NT_GNU_PROPERTIES_X86_ISA_1_486           (1U << 0)
> #define NT_GNU_PROPERTIES_X86_ISA_1_586           (1U << 1)
> #define NT_GNU_PROPERTIES_X86_ISA_1_686           (1U << 2)
> #define NT_GNU_PROPERTIES_X86_ISA_1_SSE           (1U << 3)
> #define NT_GNU_PROPERTIES_X86_ISA_1_SSE2          (1U << 4)
> #define NT_GNU_PROPERTIES_X86_ISA_1_SSE3          (1U << 5)
> #define NT_GNU_PROPERTIES_X86_ISA_1_SSSE3         (1U << 6)
> #define NT_GNU_PROPERTIES_X86_ISA_1_SSE4_1        (1U << 7)
> #define NT_GNU_PROPERTIES_X86_ISA_1_SSE4_2        (1U << 8)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX           (1U << 9)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX2          (1U << 10)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512F       (1U << 11)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512CD      (1U << 12)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512ER      (1U << 13)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512PF      (1U << 14)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512VL      (1U << 15)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512DQ      (1U << 16)
> #define NT_GNU_PROPERTIES_X86_ISA_1_AVX512BW      (1U << 17)
>

RFC: Program Properties

[H.J. Lu]

There are cases where linker and run-time loader need more information
about ELF objects beyond what the current gABI provides:

1. Minimum ISAs.  Executables and shared objects, which are optimized
specifically to run on a particular processor, will not run on processors
which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
information to tell if an executable or a shared object is compatible
with available ISAs.
2. Stack size.  Compilers may generate binaries which require larger stack
size than normal.  If run-time loader can query the stack size required
by executable or shared object, it can increase stack size as needed.
3. Copy relocation and protected visibility are fundamentally incompatible.
On one hand, copy relocation is the part of the psABI and is used to
access global data defined in a shared object from the executable.  It
moves the definition of global data, which is defined in a share object,
to the executable at run-time.  On the other hand, protected visibility
indicates that a symbol is defined locally in the shared object at
run-time.  Both can't be true at the same time.  The current solution
is to make protected symbol more or less like normal symbol, which
prevents optimizing local access to protected symbol within the shared
object.

GNU attributes

GNU binutils supports build attribute and run-time platform compatibility
data in relocatable object files.  Issues with GNU attributes:

1. Many architectures, including x86, don't support GNU attributes.
2. On x86, linking a relocatable object full of AVX instructions doesn't
always make the resulting executables or shared libraries to require AVX
to run since AVX functions may be called only via GNU_IFUNC at run-time.
Linker can't set minimum ISAs just from ISAs used by input relocatable
objects.
3. There is no program segment for GNU attributes in executables and
shared objects.
4. Most of attributes aren't applicable to run-time loader.
5. The format of GNU attributes isn't optimal for run-time loader.  A
separate string table is used to store string attributes.

gABI support for program properties

To the "Special Sections" section, add:

     Name                Type                 Attributes
.note.gnu.property.0    SHT_NOTE              SHF_ALLOC

A .note.GNU-properties section contains a property note descriptor,
starting with a property note descriptor header and followed by an array
of properties.  It can be merged with other SHT_NOTE sections.  The
property note descriptor header has the following structure:

typedef struct {
  Elf_Word namsz;
  Elf_Word descsz;
  Elf_Word type;
  unsigned char name[4];
} Elf_GNU_Notehdr;

1. namesz is 4.
2. descsz contains the size of the property array.
3. type specifies the property type:

#define NT_GNU_PROPERTY_TYPE_0   5

4. name is a null-terminated character string. It should be "GNU".

Each array element represents one property with type, data size and data.
In 64-bit objects, each element is an array of 8-byte words, whose first
element is 4-byte type and data size, in the format of the target processor.
In 32-bit objects, each element is an array of 4-byte words, whose first 2
elements are 4-byte type and data size, in the format of the target
processor.  An array element has the following structure:

typedef struct {
  Elf_Word pr_type;
  Elf_Word pr_datasz;
  unsigned char pr_data[PR_DATASZ];
  unsigned char pr_padding[PR_PADDING];
} Elf_Prop;

where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
array element to 8 or 4-byte alignment (depending on whether the file
is a 64-bit or 32-bit object).  The array elements are sorted by the
property type.  The interpretation of property array depends on both
ph_kind and pr_type.

Types of program properties

#define GNU_PROPERTY_LOPROC        0xb0000000
#define GNU_PROPERTY_HIPROC        0xdfffffff
#define GNU_PROPERTY_LOUSER        0xe0000000
#define GNU_PROPERTY_HIUSER        0xffffffff

Proposed properties

For NT_GNU_PROPERTY_TYPE_0:

#define GNU_PROPERTY_STACK_SIZE              1

Integer value for minimum stack size.

#define GNU_PROPERTY_NO_COPY_ON_PROTECTED    2

This indicates that there should be no copy relocations against protected
data symbols.  If a relocatable object contains this property, linker
should treat protected data symbol as defined locally at run-time and copy
this property to the output share object.  Run-time loader should disallow
copy relocations against protected data symbols defined in share objects
with GNU_PROPERTY_NO_COPY_ON_PROTECTED property.

#define GNU_PROPERTY_X86_ISA_1_USED          0xc0000000

The x86 instruction sets indicated by the corresponding bits are used
in program.  But their support in the hardware is optional.

#define GNU_PROPERTY_X86_ISA_1_NEEDED        0xc0000001

The x86 instruction sets indicated by the corresponding bits are used
in program and they must be supported by the hardware.  A bit set in
GNU_PROPERTY_X86_ISA_1_NEEDED must also be set in
GNU_PROPERTY_X86_ISA_1_USED.

Integer value for the x86 instruction set support.

#define GNU_PROPERTY_X86_ISA_1_486           (1U << 0)
#define GNU_PROPERTY_X86_ISA_1_586           (1U << 1)
#define GNU_PROPERTY_X86_ISA_1_686           (1U << 2)
#define GNU_PROPERTY_X86_ISA_1_SSE           (1U << 3)
#define GNU_PROPERTY_X86_ISA_1_SSE2          (1U << 4)
#define GNU_PROPERTY_X86_ISA_1_SSE3          (1U << 5)
#define GNU_PROPERTY_X86_ISA_1_SSSE3         (1U << 6)
#define GNU_PROPERTY_X86_ISA_1_SSE4_1        (1U << 7)
#define GNU_PROPERTY_X86_ISA_1_SSE4_2        (1U << 8)
#define GNU_PROPERTY_X86_ISA_1_AVX           (1U << 9)
#define GNU_PROPERTY_X86_ISA_1_AVX2          (1U << 10)
#define GNU_PROPERTY_X86_ISA_1_AVX512F       (1U << 11)
#define GNU_PROPERTY_X86_ISA_1_AVX512CD      (1U << 12)
#define GNU_PROPERTY_X86_ISA_1_AVX512ER      (1U << 13)
#define GNU_PROPERTY_X86_ISA_1_AVX512PF      (1U << 14)
#define GNU_PROPERTY_X86_ISA_1_AVX512VL      (1U << 15)
#define GNU_PROPERTY_X86_ISA_1_AVX512DQ      (1U << 16)
#define GNU_PROPERTY_X86_ISA_1_AVX512BW      (1U << 17)


-- 
H.J.

Re: RFC: Program Properties

[Nick Clifton]

Hi Guys,

  It looks like we are all working towards a common goal, which is good.

  H.J. - I like your program property scheme, especially the idea of having
  a lightweight, allocatable section that can be quickly parsed by the loader.

  I assume that the NT_GNU_PROPERTY_TYPE_0 note type also serves as a version
  indicator ?  Ie future versions of the specification would use a different
  value to indicate newer features ?

  One thing that I would like to propose is an extension to the scheme to add
  a second, larger note section that is not allocatable, but which instead
  contains information to be parsed by static tools.  In particular this
  section would contain information about the tools used to build the binary
  and the security features enabled (or disabled).  Also this section would
  be able to discriminate this information on a per-symbol basis if necessary,
  so that multiple, conflicting properties can be recorded for a single file.

  I have a preliminary proposal to implement this second section (see below)
  and I would be very interested in any thoughts that you might have.

Cheers
  Nick

The purpose of this non-allocatable note section is to provide a way for
package maintainers and distributions to answer questions about the binaries
in their distribution.  Especially security related questions.  Here is the
current, preliminary, specification:

* The information is stored in a new section in the file using the ELF
  NOTE format.  Creator tools (compilers, assemblers etc) place the notes
  into the binary files.  Consumer tools (none written yet, but readelf 
  and/or objdump could be enhanced for this purpose) read the notes and
  answer questions about the binaries concerned.  Static linkers need
  special care to handle merging of the notes.

* The information is stored in a section called .gnu.build.attributes.
  (The name can be changed - it is basically irrelevant anyway, it is
  the new section flag (defined below) that matters).   The section has 
  the SHT_NOTE type and a new section flag set: SHF_GNU_BUILD_ATTRIBUTES.
  (Suggested value: 0x00100000).  This ndicates the special needs when
  merging notes (see below).

  The sh_link field should be set to contain the index of symbol table
  section.  If this field is 0 then the consumer should assume that
  the first section of type SHT_SYMTAB in the section headers is
  symbol table being used.

* The specification breaks the name/description convention of ELF
  notes to instead use a key/value/applies-to list.  (This not a
  problem as we are only breaking a convention not a requirement of
  the ELF NOTE specification).  The type of the note is the key.  The
  name of the note is the value and the description field is the
  applies-to list.

  By default the description field contains the filename of the source
  file that was used to produce the binary.  (FIXME: Absolute pathname
  ?  Relative pathname ?  Just the filename with no path ?)  This
  indicates that the key/value pair applies to all symbols in the
  file.  The length of this string must *not* be multiple of 4 (with
  the terminating NUL byte included).  If necessary the filename
  should be padded with an extra NUL byte.  (Note - this padding byte
  is separate from the padding bytes used to align the description
  field to its normal boundary).

  This restriction is so that a description containing symbol names
  (see below) can be distinguished from a description containing a
  file name.

  If a key/value pair applies to just some of the symbols in a file,
  then the description instead contains a list of 4-byte or 8-byte wide 
  numbers.  These are indices into the symbol table, (pointed to by 
  the sh_link field of the section header).  Notes:
  
    + In unrelocated files the offset should instead be zero, with a
      relocation present to set the actual value once the file is
      linked.  FIXME: Unable to implement at the moment.  Instead
      the relocation generated by the assembler evaluates to *value*
      of the symbol not its index in the ELF symbol table section.
      May have to change this spec if I cannot find a way around
      this.

    + The numbers are stored in the same endian format as that
      specified in the EI_DATA field of the ELF header of the file
      containing the note.

    + The symbol table is indexed rather than the string table because
      consumers are most likely to be interested the symbol as a
      whole, not just its name.  (FIXME: Is this true ?)      

  An empty description field is a special case.  It should be treated
  as if it had the same filename as the nearest preceding version
  note.  (See NT_GNU_BUILD_ATTRIBUTE_VERSION below).  FIXME: This
  assumes that a linker will preserve the order of notes when
  linking.  Does this actually happen ?

  Multiple notes of the same key can exist, providing that they have
  different values and that their applies-to lists do not intersect.
  (FIXME: is this restriction necessary ?  Perhaps there are times when
  a symbol can have multiple values for the same key).

  Where notes for the same key exist in both symbol index form and
  filename form, the symbol index form takes precedence.  Any symbol
  in the given file not explicitly indexed by one of the notes will
  take its value from the note using the filename form.

  At most one note for a given key can exist containing a filename
  rather than symbol indices.  If this rule is broken then this
  indicates that the file has been created by a linker that has not
  been enhanced to support this specification.  In such cases all
  notes containing symbol indices should be ignored.


* When the linker merges two or more files containing these notes it
  should ensure that the above rules are maintained, and that the
  notes are merged appropriately.

  The linker will create a new version note (see the definition of
  NT_GNU_BUILD_ATTRIBUTE_VERSION below), with the output filename as
  its description, and the name set to any version of this
  specification that it chooses.  Any input version notes that match
  this version are discarded.  Other version notes are preserved and
  included in the output file.

  When notes are merged the following rules apply:

   1. If all input notes of a given type just contain filenames and
      they all have the same value string then a single output note is
      created with this type/value and the output filename as its
      description.  Otherwise:

   2. If rule 1 would match except for one or more symbol containing
      notes then rule 1 is executed, but the symbol containing notes
      are also preserved and copied to the output.  If this is a
      relocatable link then the relocations associated with the symbol
      indices should also be updated.  Otherwise:

  3.  [This rule triggers if there are filename containing notes with
      different value strings].  The linker chooses one of the input
      value strings to be the default for the output and creates an
      output note using this value.  (Presumably the linker will
      choose the value with the most matching input files).  Input
      notes containing filenames but with a value that does not match
      this output value must be converted into symbol containing notes
      listing *all* of the symbols in the input file.  Failure to do
      this breaks the requirement that there only be one filename
      containing output note for the given key.

  If this is a final link, then relocations on the notes should of
  course be resolved.

  The linker is also able to create and insert its own notes.  Eg to
  indicate that -z relro is enabled.

  Linkers that have not been enhanced to support this proposal will
  simply concatenate the notes.  (They may also eliminate duplicate
  notes, although this is not guaranteed.  They may also sort the
  notes which would break the use of empty description fields, as
  mentioned above).  In this case the output file is likely to contain
  multiple notes with the same key/value pair.  Consumers can detect
  this situation by noticing that there is no
  NT_GNU_BUILD_ATTRIBUTE_VERSION note with output file name, and hence
  deduce that any notes containing symbol indices are broken.  (The
  linker will not have updated the indices when merging the notes).
  Despite only supporting a file level granularity however, these
  notes may still prove useful.


* Three new note types defined (so far):

  Type: NT_GNU_BUILD_ATTRIBUTE_VERSION  (0x100)
  Name: A string identifying the version of this specification
        that is implemented in the accompanying notes.  Currently set
        to "1.0".

  Type: NT_GNU_BUILD_ATTRIBUTE_CREATOR  (0x101)
  Name: A string identifying the tool that created the symbols and
        their associated code eg:
        "gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)"
        includes name, date and version.

  Type: NT_GNU_BUILD_ATTRIBUTE_OPTIONS  (0x102)
  Name: A string identifying the *significant* compile time options
        affecting the specified symbols.  Ie those that affect ABI,
        security, etc. 

        Note: selection of *significant* compile time options may be
        subject to debate.  But the actual choice can vary over time,
        this does not affect the current proposal.

Re: RFC: Program Properties

[Suprateeka R Hegde]

On 13-Oct-2016 05:07 PM, Jose E. Marchesi wrote:
>
>     > 1. Minimum ISAs.  Executables and shared objects, which are optimized
>     > specifically to run on a particular processor, will not run on processors
>     > which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
>     > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
>     > information to tell if an executable or a shared object is compatible
>     > with available ISAs.
>
>     Why cant the following be defined as processor specific e_flags (like
>     other processors do) in elf.h itself?
>
> It is easy to exhaust the space of EF_* flags.  In sparc this happened
> many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS
> and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities.

Hmm. Looks reasonable. But I still have some points to ponder:

e_flags is processor specific and I thought each processor has its own 
space. And e_flags is also 4 byte size (purpose is unsigned integer).

The proposed numbering scheme is already at 17 and 14 more left-shifts 
left. It would be same as e_flags capacity.

In addition, we can have arch-version mask just like Intel Itanium, 
MIPS, etc. Of course thats slightly expensive but gives more space. And 
if we can add asserts in compilers/binutils to check the range of 
e_flags to be within the mask, then we can make it efficient too.

Am I missing anything?/

--
Supra

Re: RFC: Program Properties

[Suprateeka R Hegde]

On 12-Oct-2016 11:33 PM, H.J. Lu wrote:
> 1. Minimum ISAs.  Executables and shared objects, which are optimized
> specifically to run on a particular processor, will not run on processors
> which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
> EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
> information to tell if an executable or a shared object is compatible
> with available ISAs.

Why cant the following be defined as processor specific e_flags (like 
other processors do) in elf.h itself?

Instead of GNU_PROPERT_X86_*, why cant we have EF_X86_* (and adjust the 
mechanism/logic of the proposal accordingly) ? That would make it 
uniform at least as per elf.h.

X86, as a processor architecture, need not be tied to GNU?


> Integer value for the x86 instruction set support.
>
> #define GNU_PROPERTY_X86_ISA_1_486           (1U << 0)
> #define GNU_PROPERTY_X86_ISA_1_586           (1U << 1)
> #define GNU_PROPERTY_X86_ISA_1_686           (1U << 2)
> #define GNU_PROPERTY_X86_ISA_1_SSE           (1U << 3)
> #define GNU_PROPERTY_X86_ISA_1_SSE2          (1U << 4)
> #define GNU_PROPERTY_X86_ISA_1_SSE3          (1U << 5)
> #define GNU_PROPERTY_X86_ISA_1_SSSE3         (1U << 6)
> #define GNU_PROPERTY_X86_ISA_1_SSE4_1        (1U << 7)
> #define GNU_PROPERTY_X86_ISA_1_SSE4_2        (1U << 8)
> #define GNU_PROPERTY_X86_ISA_1_AVX           (1U << 9)
> #define GNU_PROPERTY_X86_ISA_1_AVX2          (1U << 10)
> #define GNU_PROPERTY_X86_ISA_1_AVX512F       (1U << 11)
> #define GNU_PROPERTY_X86_ISA_1_AVX512CD      (1U << 12)
> #define GNU_PROPERTY_X86_ISA_1_AVX512ER      (1U << 13)
> #define GNU_PROPERTY_X86_ISA_1_AVX512PF      (1U << 14)
> #define GNU_PROPERTY_X86_ISA_1_AVX512VL      (1U << 15)
> #define GNU_PROPERTY_X86_ISA_1_AVX512DQ      (1U << 16)
> #define GNU_PROPERTY_X86_ISA_1_AVX512BW      (1U << 17)

--
Supra

Re: RFC: Program Properties

[H.J. Lu]

On Mon, Oct 17, 2016 at 6:32 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
> On Thu, 13 Oct 2016, Carlos O'Donell wrote:
>
>> > There are cases where linker and run-time loader need more information
>> > about ELF objects beyond what the current gABI provides:
>>
>> I like the idea. Nick Clifton and I were discussing this at GNU Cauldron 2016.
>
>  I wish I was there. :(
>
>> (6) Is there any historical implementations of anything like this?
>
>  The MIPS target has been using a mixture of ELF file header's `e_flags'
> member flags (EF_MIPS_*) which we have now run out of, GNU attributes
> (Tag_GNU_MIPS_ABI_*, Val_GNU_MIPS_ABI_*) interpreted by the static linker
> only, and more recently a processor-specific "MIPS ABI Flags" section
> (SHT_MIPS_ABIFLAGS) and segment (PT_MIPS_ABIFLAGS).  Some of this
> information although not necessarily all at once is interpreted by the
> static linker, the Linux kernel (e.g. to verify the compatibility of a
> binary against hardware and the dynamic loader), and finally the dynamic
> loader.
>
>  I think it would make sense if the design of program properties let us
> wire the existing target-specific data structures if possible, so that
> e.g. a MIPS ABI Flags section/segment could be interpreted as a part of
> the new data structures.
>
>  Also based on the experience with MIPS ABI Flags so far I would suggest
> defining generic ABI flag flags so that individual object file's ABI flags
> can be handled in a generic way in linking; the flags I'd initially
> propose would be:
>
> 1. An OR flag: if such annotated the ABI flag produced in output is a
>    logical OR of the values of the ABI flag in input objects.

Reasonable.

> 2. An AND flag: if such annotated the ABI flag produced in output is a
>    logical AND of the values of the ABI flag in input objects.

Reasonable.

> 3. An equality flag: if such annotated linking fails if the values of the
>    ABI flag in input objects are not the same across all of them.

Reasonable.

> 4. A reject flag: if such annotated the ABI flag requires explicit support
>    (special handling beyond the three variants above) and linking fails if
>    it is set in any input object and the linker does know this ABI flag.

"reject" isn't very clear.  Is "mandatory" better?

> Such annotation would of course have to be consistent across input files.
>
>  Such ABI flag flags would allow ABIs to define new ABI flags processed
> automatically in static linking without the need to upgrade the linker
> each time a flag is added.
>
>  Thoughts?

Property values can be divided into ranges of different rules, including
rules which differ from above.

-- 
H.J.

Re: RFC: Program Properties

[H.J. Lu]

On Thu, Oct 13, 2016 at 7:24 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/12/2016 02:03 PM, H.J. Lu wrote:
>> There are cases where linker and run-time loader need more information
>> about ELF objects beyond what the current gABI provides:
>
> I like the idea. Nick Clifton and I were discussing this at GNU Cauldron 2016.
>
> I appreciate you have come up with some concrete examples, but I think we
> need to take these example and flesh them out completely and see if we have
> any problems with your proposed model. Can you pick one of the examples and
> flesh out how the bits move from the compiler to assembler to static linker
> to dynamic linker and what happens then?
>
> To kick off that discussion I have questions that range from the compiler
> to the dynamic loader:
>
> (1) How coarse or how fine do you see this checking happening? The current object
> you propose, Elf_Prop, is very generic. Could we model more and make life easier
> for consumers?

The consumers of my proposal are linker and loader.  It provided a way
to describe program properties to them for the whole object file.

> (2) Can you have one ore more pr_type Elf_Prop's in the single object?

A sngle object file has one .note.gnu.property.0 note section which is
an array of Elf_Prop.  If we run out of property types, we can add
another property note section.

> (3) Can we use Elf_Prop's to mark per-function properties by expressing the function
> to be described in pr_data? Perhaps using dwarf? Again, could we model more to
> make consumer's simpler to write?

Program property covers the whole object file, not individual functions.
We can add an auxiliary symbol table for function property.

> (4) How do we deal with data-dependent executions that are known to use only
> a subset of the shared object features? For example consider code which doesn't use
> IFUNCs but instead checks the CPU type, and conditionally executes code, such a
> function would be automatically marked as *_NEEDED for all the relevant ISAs,
> when it's not true and works today. Do we need to define compiler function attributes
> to allow users to change or override the program properties e.g. allow the user
> to specify the properties exaclty, disabling automatic generation?

AVX is marked as needed only if the program won't run without AVX.
In most cases, compiler doesn't know if it is true even when AVX is
generated.  Only developers know that.

> (5) I assume the merging of the notes is dependent on the pr_type and has to have
> custom code for that merging?

That is correct.

> (6) Is there any historical implementations of anything like this?
>

GNU attribute? But it isn't for run-time loader.

-- 
H.J.

Re: RFC: Program Properties

[H.J. Lu]

On Tue, Oct 25, 2016 at 4:46 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
> On Mon, 17 Oct 2016, H.J. Lu wrote:
>
>> > 4. A reject flag: if such annotated the ABI flag requires explicit support
>> >    (special handling beyond the three variants above) and linking fails if
>> >    it is set in any input object and the linker does know this ABI flag.
>>
>> "reject" isn't very clear.  Is "mandatory" better?
>
>  Such property seen by the component addressed (be it the static linker,
> dynamic loader or OS kernel) would cause the binary to be rejected unless
> already explicitly recognised by the component.  Or IOW unknown such
> properties would be rejected and known ones handled as required.  Hence
> the name proposed.
>
>  That written, having thought about it some more, I think we don't
> actually need such an explicit flag as I think we can reasonably set this
> semantics as the default.  That is any unknown property *not* annotated
> with one of the known flags would be rejected, making an explicit "reject"
> flag redundant.
>
>> > Such annotation would of course have to be consistent across input files.
>> >
>> >  Such ABI flag flags would allow ABIs to define new ABI flags processed
>> > automatically in static linking without the need to upgrade the linker
>> > each time a flag is added.
>> >
>> >  Thoughts?
>>
>> Property values can be divided into ranges of different rules, including
>> rules which differ from above.
>
>  I'm not sure defining fixed ranges has an advantage over using property
> annotation.  I think it's hard to assess beforehand how many values we may
> need in each range and if we make a range allocated too narrow, then we
> risk running out of entries within, whereas if we make one too broad, then

We can add another property note if we run out of property types.

> we risk running out of the allocation space.  On the other hand by using
> explicit property annotation we will only have consumed as much of the
> allocation space as has actually been defined at any point in time.
>
>  Have I missed anything?
>

The question is where annotation is stored.  It is either stored in
property type or property data.  If it is encoded in type, it will limit
number of usable types.  It it hard to tell how many types will
be needed in the future.  I can't image that we need hundreds
of property types in a file and we can always add a new note if needed.
If it is encoded in data, it should be stored in the first few bytes,
which increases data size or make run-time processing less efficient
because of little endian vs big endian.

We can first identify how many different annotations we need and
figure out what the best way to encode them for both extensibility
as well as run-time efficiency.

-- 
H.J.

Re: RFC: Program Properties

[H.J. Lu]

On Tue, Oct 18, 2016 at 8:16 AM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
>   It looks like we are all working towards a common goal, which is good.
>
>   H.J. - I like your program property scheme, especially the idea of having
>   a lightweight, allocatable section that can be quickly parsed by the loader.
>
>   I assume that the NT_GNU_PROPERTY_TYPE_0 note type also serves as a version
>   indicator ?  Ie future versions of the specification would use a different
>   value to indicate newer features ?

Each property note entry, identified by note type, supports up to 4G
different properties.  I only defined NT_GNU_PROPERTY_TYPE_0.
We can add another one if we run out of available properties.

>   One thing that I would like to propose is an extension to the scheme to add
>   a second, larger note section that is not allocatable, but which instead
>   contains information to be parsed by static tools.  In particular this
>   section would contain information about the tools used to build the binary
>   and the security features enabled (or disabled).  Also this section would
>   be able to discriminate this information on a per-symbol basis if necessary,
>   so that multiple, conflicting properties can be recorded for a single file.
>
>   I have a preliminary proposal to implement this second section (see below)
>   and I would be very interested in any thoughts that you might have.
>
> Cheers
>   Nick
>
> The purpose of this non-allocatable note section is to provide a way for
> package maintainers and distributions to answer questions about the binaries
> in their distribution.  Especially security related questions.  Here is the
> current, preliminary, specification:
>
> * The information is stored in a new section in the file using the ELF
>   NOTE format.  Creator tools (compilers, assemblers etc) place the notes
>   into the binary files.  Consumer tools (none written yet, but readelf
>   and/or objdump could be enhanced for this purpose) read the notes and
>   answer questions about the binaries concerned.  Static linkers need
>   special care to handle merging of the notes.
>
> * The information is stored in a section called .gnu.build.attributes.
>   (The name can be changed - it is basically irrelevant anyway, it is
>   the new section flag (defined below) that matters).   The section has
>   the SHT_NOTE type and a new section flag set: SHF_GNU_BUILD_ATTRIBUTES.
>   (Suggested value: 0x00100000).  This ndicates the special needs when
>   merging notes (see below).
>
>   The sh_link field should be set to contain the index of symbol table
>   section.  If this field is 0 then the consumer should assume that
>   the first section of type SHT_SYMTAB in the section headers is
>   symbol table being used.

It doesn't sound like a note section, whose content should be
described by the note type.  Will a new section type work
better?

> * The specification breaks the name/description convention of ELF
>   notes to instead use a key/value/applies-to list.  (This not a
>   problem as we are only breaking a convention not a requirement of
>   the ELF NOTE specification).  The type of the note is the key.  The
>   name of the note is the value and the description field is the
>   applies-to list.
>
>   By default the description field contains the filename of the source
>   file that was used to produce the binary.  (FIXME: Absolute pathname
>   ?  Relative pathname ?  Just the filename with no path ?)  This
>   indicates that the key/value pair applies to all symbols in the
>   file.  The length of this string must *not* be multiple of 4 (with
>   the terminating NUL byte included).  If necessary the filename
>   should be padded with an extra NUL byte.  (Note - this padding byte
>   is separate from the padding bytes used to align the description
>   field to its normal boundary).
>
>   This restriction is so that a description containing symbol names
>   (see below) can be distinguished from a description containing a
>   file name.
>
>   If a key/value pair applies to just some of the symbols in a file,
>   then the description instead contains a list of 4-byte or 8-byte wide
>   numbers.  These are indices into the symbol table, (pointed to by
>   the sh_link field of the section header).  Notes:
>
>     + In unrelocated files the offset should instead be zero, with a
>       relocation present to set the actual value once the file is
>       linked.  FIXME: Unable to implement at the moment.  Instead
>       the relocation generated by the assembler evaluates to *value*
>       of the symbol not its index in the ELF symbol table section.
>       May have to change this spec if I cannot find a way around
>       this.
>
>     + The numbers are stored in the same endian format as that
>       specified in the EI_DATA field of the ELF header of the file
>       containing the note.
>
>     + The symbol table is indexed rather than the string table because
>       consumers are most likely to be interested the symbol as a
>       whole, not just its name.  (FIXME: Is this true ?)
>
>   An empty description field is a special case.  It should be treated
>   as if it had the same filename as the nearest preceding version
>   note.  (See NT_GNU_BUILD_ATTRIBUTE_VERSION below).  FIXME: This
>   assumes that a linker will preserve the order of notes when
>   linking.  Does this actually happen ?
>
>   Multiple notes of the same key can exist, providing that they have
>   different values and that their applies-to lists do not intersect.
>   (FIXME: is this restriction necessary ?  Perhaps there are times when
>   a symbol can have multiple values for the same key).
>
>   Where notes for the same key exist in both symbol index form and
>   filename form, the symbol index form takes precedence.  Any symbol
>   in the given file not explicitly indexed by one of the notes will
>   take its value from the note using the filename form.
>
>   At most one note for a given key can exist containing a filename
>   rather than symbol indices.  If this rule is broken then this
>   indicates that the file has been created by a linker that has not
>   been enhanced to support this specification.  In such cases all
>   notes containing symbol indices should be ignored.
>
>
> * When the linker merges two or more files containing these notes it
>   should ensure that the above rules are maintained, and that the
>   notes are merged appropriately.
>
>   The linker will create a new version note (see the definition of
>   NT_GNU_BUILD_ATTRIBUTE_VERSION below), with the output filename as
>   its description, and the name set to any version of this
>   specification that it chooses.  Any input version notes that match
>   this version are discarded.  Other version notes are preserved and
>   included in the output file.
>
>   When notes are merged the following rules apply:
>
>    1. If all input notes of a given type just contain filenames and
>       they all have the same value string then a single output note is
>       created with this type/value and the output filename as its
>       description.  Otherwise:
>
>    2. If rule 1 would match except for one or more symbol containing
>       notes then rule 1 is executed, but the symbol containing notes
>       are also preserved and copied to the output.  If this is a
>       relocatable link then the relocations associated with the symbol
>       indices should also be updated.  Otherwise:
>
>   3.  [This rule triggers if there are filename containing notes with
>       different value strings].  The linker chooses one of the input
>       value strings to be the default for the output and creates an
>       output note using this value.  (Presumably the linker will
>       choose the value with the most matching input files).  Input
>       notes containing filenames but with a value that does not match
>       this output value must be converted into symbol containing notes
>       listing *all* of the symbols in the input file.  Failure to do
>       this breaks the requirement that there only be one filename
>       containing output note for the given key.
>
>   If this is a final link, then relocations on the notes should of
>   course be resolved.
>
>   The linker is also able to create and insert its own notes.  Eg to
>   indicate that -z relro is enabled.
>
>   Linkers that have not been enhanced to support this proposal will
>   simply concatenate the notes.  (They may also eliminate duplicate
>   notes, although this is not guaranteed.  They may also sort the
>   notes which would break the use of empty description fields, as
>   mentioned above).  In this case the output file is likely to contain
>   multiple notes with the same key/value pair.  Consumers can detect
>   this situation by noticing that there is no
>   NT_GNU_BUILD_ATTRIBUTE_VERSION note with output file name, and hence
>   deduce that any notes containing symbol indices are broken.  (The
>   linker will not have updated the indices when merging the notes).
>   Despite only supporting a file level granularity however, these
>   notes may still prove useful.
>
>
> * Three new note types defined (so far):
>
>   Type: NT_GNU_BUILD_ATTRIBUTE_VERSION  (0x100)
>   Name: A string identifying the version of this specification
>         that is implemented in the accompanying notes.  Currently set
>         to "1.0".
>
>   Type: NT_GNU_BUILD_ATTRIBUTE_CREATOR  (0x101)
>   Name: A string identifying the tool that created the symbols and
>         their associated code eg:
>         "gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)"
>         includes name, date and version.
>
>   Type: NT_GNU_BUILD_ATTRIBUTE_OPTIONS  (0x102)
>   Name: A string identifying the *significant* compile time options
>         affecting the specified symbols.  Ie those that affect ABI,
>         security, etc.
>
>         Note: selection of *significant* compile time options may be
>         subject to debate.  But the actual choice can vary over time,
>         this does not affect the current proposal.
>



-- 
H.J.

Re: RFC: Program Properties

[Maciej W. Rozycki]

On Thu, 13 Oct 2016, Carlos O'Donell wrote:

> > There are cases where linker and run-time loader need more information
> > about ELF objects beyond what the current gABI provides:
> 
> I like the idea. Nick Clifton and I were discussing this at GNU Cauldron 2016.

 I wish I was there. :(

> (6) Is there any historical implementations of anything like this?

 The MIPS target has been using a mixture of ELF file header's `e_flags' 
member flags (EF_MIPS_*) which we have now run out of, GNU attributes 
(Tag_GNU_MIPS_ABI_*, Val_GNU_MIPS_ABI_*) interpreted by the static linker 
only, and more recently a processor-specific "MIPS ABI Flags" section 
(SHT_MIPS_ABIFLAGS) and segment (PT_MIPS_ABIFLAGS).  Some of this 
information although not necessarily all at once is interpreted by the 
static linker, the Linux kernel (e.g. to verify the compatibility of a 
binary against hardware and the dynamic loader), and finally the dynamic 
loader.

 I think it would make sense if the design of program properties let us 
wire the existing target-specific data structures if possible, so that 
e.g. a MIPS ABI Flags section/segment could be interpreted as a part of 
the new data structures.

 Also based on the experience with MIPS ABI Flags so far I would suggest 
defining generic ABI flag flags so that individual object file's ABI flags 
can be handled in a generic way in linking; the flags I'd initially 
propose would be:

1. An OR flag: if such annotated the ABI flag produced in output is a 
   logical OR of the values of the ABI flag in input objects.

2. An AND flag: if such annotated the ABI flag produced in output is a 
   logical AND of the values of the ABI flag in input objects.

3. An equality flag: if such annotated linking fails if the values of the 
   ABI flag in input objects are not the same across all of them.

4. A reject flag: if such annotated the ABI flag requires explicit support 
   (special handling beyond the three variants above) and linking fails if 
   it is set in any input object and the linker does know this ABI flag.

Such annotation would of course have to be consistent across input files.

 Such ABI flag flags would allow ABIs to define new ABI flags processed 
automatically in static linking without the need to upgrade the linker 
each time a flag is added.

 Thoughts?

  Maciej

Re: RFC: Program Properties

[Suprateeka R Hegde]

On 21-Oct-2016 11:16 PM, H.J. Lu wrote:

> On Tue, Oct 18, 2016 at 8:16 AM, Nick Clifton <nickc@redhat.com> wrote:

>>
>> * The information is stored in a new section in the file using the ELF
>>   NOTE format.  Creator tools (compilers, assemblers etc) place the notes
>>   into the binary files.  Consumer tools (none written yet, but readelf
>>   and/or objdump could be enhanced for this purpose) read the notes and
>>   answer questions about the binaries concerned.  Static linkers need
>>   special care to handle merging of the notes.
>>
>> * The information is stored in a section called .gnu.build.attributes.
>>   (The name can be changed - it is basically irrelevant anyway, it is
>>   the new section flag (defined below) that matters).   The section has
>>   the SHT_NOTE type and a new section flag set: SHF_GNU_BUILD_ATTRIBUTES.
>>   (Suggested value: 0x00100000).  This ndicates the special needs when
>>   merging notes (see below).
>>
>>   The sh_link field should be set to contain the index of symbol table
>>   section.  If this field is 0 then the consumer should assume that
>>   the first section of type SHT_SYMTAB in the section headers is
>>   symbol table being used.
>
> It doesn't sound like a note section, whose content should be
> described by the note type.  Will a new section type work
> better?

On HP-UX, we have similar stuff (build attributes) that records 
information about build tools, time stamps, entire command line options, 
and many more.

However, we do store this as a note type, but make it HP-UX specific 
(.note.hp-ux...). We also have a tool called "footrprints" which parses 
this note and prints the info in a very user friendly way. However, in 
certain cases, the granularity of the information may not be upto symbol 
level; it is only upto individual relocatable object file level.

Any reason why you think it does not sound like a note type?

BTW, I am happy that my thoughts mentioned in the psABI 
(https://goo.gl/fgRa20) would be fulfilled as part of this big proposal.

--
Supra

Re: RFC: Program Properties

[Joseph Myers]

On Fri, 14 Oct 2016, Suprateeka R Hegde wrote:

> And then propagate this to archive libraries too. For instance, allow an
> archive library to contain two foo.o files one built with minimum ISA-1 and
> another built with minimum ISA-2. And depending on the main program's minimum
> ISA, let the linker pick the right one.

Note that I've heard reports that there may be an ARM patent on linker 
library selection based on object file properties, but don't know the 
details.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFC: Program Properties

[Jose E. Marchesi]

    > 1. Minimum ISAs.  Executables and shared objects, which are optimized
    > specifically to run on a particular processor, will not run on processors
    > which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
    > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
    > information to tell if an executable or a shared object is compatible
    > with available ISAs.
    
    Why cant the following be defined as processor specific e_flags (like
    other processors do) in elf.h itself?

It is easy to exhaust the space of EF_* flags.  In sparc this happened
many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS
and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities.

Re: RFC: Program Properties

[H.J. Lu]

On Wed, Oct 26, 2016 at 11:15 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Oct 25, 2016 at 4:46 AM, Maciej W. Rozycki <macro@imgtec.com> wrote:
>> On Mon, 17 Oct 2016, H.J. Lu wrote:
>>
>>> > 4. A reject flag: if such annotated the ABI flag requires explicit support
>>> >    (special handling beyond the three variants above) and linking fails if
>>> >    it is set in any input object and the linker does know this ABI flag.
>>>
>>> "reject" isn't very clear.  Is "mandatory" better?
>>
>>  Such property seen by the component addressed (be it the static linker,
>> dynamic loader or OS kernel) would cause the binary to be rejected unless
>> already explicitly recognised by the component.  Or IOW unknown such
>> properties would be rejected and known ones handled as required.  Hence
>> the name proposed.
>>
>>  That written, having thought about it some more, I think we don't
>> actually need such an explicit flag as I think we can reasonably set this
>> semantics as the default.  That is any unknown property *not* annotated
>> with one of the known flags would be rejected, making an explicit "reject"
>> flag redundant.
>>
>>> > Such annotation would of course have to be consistent across input files.
>>> >
>>> >  Such ABI flag flags would allow ABIs to define new ABI flags processed
>>> > automatically in static linking without the need to upgrade the linker
>>> > each time a flag is added.
>>> >
>>> >  Thoughts?
>>>
>>> Property values can be divided into ranges of different rules, including
>>> rules which differ from above.
>>
>>  I'm not sure defining fixed ranges has an advantage over using property
>> annotation.  I think it's hard to assess beforehand how many values we may
>> need in each range and if we make a range allocated too narrow, then we
>> risk running out of entries within, whereas if we make one too broad, then
>
> We can add another property note if we run out of property types.
>
>> we risk running out of the allocation space.  On the other hand by using
>> explicit property annotation we will only have consumed as much of the
>> allocation space as has actually been defined at any point in time.
>>
>>  Have I missed anything?
>>
>
> The question is where annotation is stored.  It is either stored in
> property type or property data.  If it is encoded in type, it will limit
> number of usable types.  It it hard to tell how many types will
> be needed in the future.  I can't image that we need hundreds
> of property types in a file and we can always add a new note if needed.
> If it is encoded in data, it should be stored in the first few bytes,
> which increases data size or make run-time processing less efficient
> because of little endian vs big endian.
>
> We can first identify how many different annotations we need and
> figure out what the best way to encode them for both extensibility
> as well as run-time efficiency.
>

Here is the updated proposal with annotations in program
property types.  If we run out if types, we can add another
property notes.


-- 
H.J.
---
Program Properties

There are cases where linker and run-time loader need more information
about ELF objects beyond what the current gABI provides:

1. Minimum ISAs.  Executables and shared objects, which are optimized
specifically to run on a particular processor, will not run on processors
which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
information to tell if an executable or a shared object is compatible
with available ISAs.
2. Stack size.  Compilers may generate binaries which require larger stack
size than normal.  If run-time loader can query the stack size required
by executable or shared object, it can increase stack size as needed.
3. Copy relocation and protected visibility are fundamentally incompatible.
On one hand, copy relocation is the part of the psABI and is used to
access global data defined in a shared object from the executable.  It
moves the definition of global data, which is defined in a share object,
to the executable at run-time.  On the other hand, protected visibility
indicates that a symbol is defined locally in the shared object at
run-time.  Both can't be true at the same time.  The current solution
is to make protected symbol more or less like normal symbol, which
prevents optimizing local access to protected symbol within the shared
object.

GNU attributes

GNU binutils supports build attribute and run-time platform compatibility
data in relocatable object files.  Issues with GNU attributes:

1. Many architectures, including x86, don't support GNU attributes.
2. On x86, linking a relocatable object full of AVX instructions doesn't
always make the resulting executables or shared libraries to require AVX
to run since AVX functions may be called only via GNU_IFUNC at run-time.
Linker can't set minimum ISAs just from ISAs used by input relocatable
objects.
3. There is no program segment for GNU attributes in executables and
shared objects.
4. Most of attributes aren't applicable to run-time loader.
5. The format of GNU attributes isn't optimal for run-time loader.  A
separate string table is used to store string attributes.

gABI support for program properties

To the "Special Sections" section, add:

     Name              Type                 Attributes
.note.gnu.property    SHT_NOTE              SHF_ALLOC

A .note.gnu.property section contains at least one property note
descriptor, starting with a property note descriptor header and
followed by an array of properties.  The property note descriptor
header has the following structure:

typedef struct {
  Elf_Word namsz;
  Elf_Word descsz;
  Elf_Word type;
  unsigned char name[4];
} Elf_GNU_Notehdr;

1. namesz is 4.
2. descsz contains the size of the property array.
3. type specifies the property type:

#define NT_GNU_PROPERTY_TYPE_0   5

4. name is a null-terminated character string. It should be "GNU".

Each array element represents one property with type, data size and data.
In 64-bit objects, each element is an array of 8-byte words, whose first
element is 4-byte type and data size, in the format of the target processor.
In 32-bit objects, each element is an array of 4-byte words, whose first 2
elements are 4-byte type and data size, in the format of the target
processor.  An array element has the following structure:

typedef struct {
  Elf_Word pr_type;
  Elf_Word pr_datasz;
  unsigned char pr_data[PR_DATASZ];
  unsigned char pr_padding[PR_PADDING];
} Elf_Prop;

where PR_DATASZ is the data size and PR_PADDING, if necessary, aligns
array element to 8 or 4-byte alignment (depending on whether the file
is a 64-bit or 32-bit object).  The array elements are sorted by the
property type.  The interpretation of property array depends on both
ph_kind and pr_type.

Types of program properties

The last 3 bits of program property indicate how it should be
processed.

#define GNU_PROPERTY_TYPE_SHIFT    3
#define GNU_PROPERTY_TYPE_MASK     (-(1 << GNU_PROPERTY_TYPE_SHIFT))
#define GNU_PROPERTY_EVAL_MASK     ((1 << GNU_PROPERTY_TYPE_SHIFT) - 1)

#define GNU_PROPERTY_EVAL_REQ      0

Linker should refuse to generate output if input property type is
unknown.

#define GNU_PROPERTY_EVAL_EQ       1

Linker should refuse to generate output if input property data aren't
identical.

#define GNU_PROPERTY_EVAL_OR       2

Output property data is logical OR of input property data.

#define GNU_PROPERTY_EVAL_AND      3

Output property data is logical AND of input property data.

Linker should refuse to generate output for other evaluation values in
input property type.

#define GNU_PROPERTY_LOPROC        0xb0000000
#define GNU_PROPERTY_HIPROC        (0xdfffffff&GNU_PROPERTY_TYPE_MASK)
#define GNU_PROPERTY_LOUSER        0xe0000000
#define GNU_PROPERTY_HIUSER        (0xffffffff&GNU_PROPERTY_TYPE_MASK)

Proposed properties

For NT_GNU_PROPERTY_TYPE_0:

#define GNU_PROPERTY_STACK_SIZE \
 ((1 << GNU_PROPERTY_TYPE_SHIFT)|GNU_PROPERTY_EVAL_REQ)

Integer value for minimum stack size whose is 8 bytes in 64-bit object
and 4 bytes in 32-bit object.

#define GNU_PROPERTY_NO_COPY_ON_PROTECTED \
 ((2 << GNU_PROPERTY_TYPE_SHIFT)|GNU_PROPERTY_EVAL_REQ)

Its pr_datasz is 0.  This indicates that there should be no copy
relocations against protected data symbols.  If a relocatable object
contains this property, linker should treat protected data symbol as
defined locally at run-time and copy this property to the output share
object.  Run-time loader should disallow copy relocations against
protected data symbols defined in share objects with
GNU_PROPERTY_NO_COPY_ON_PROTECTED property.

#define GNU_PROPERTY_X86_ISA_1_USED \
  ((0 << GNU_PROPERTY_TYPE_SHIFT)|GNU_PROPERTY_LOPROC|GNU_PROPERTY_EVAL_OR)

The x86 instruction sets indicated by the corresponding bits are used
in program.  But their support in the hardware is optional.

#define GNU_PROPERTY_X86_ISA_1_NEEDED \
  ((1 << GNU_PROPERTY_TYPE_SHIFT)|GNU_PROPERTY_LOPROC|GNU_PROPERTY_EVAL_OR)

The x86 instruction sets indicated by the corresponding bits are used
in program and they must be supported by the hardware.  A bit set in
GNU_PROPERTY_X86_ISA_1_NEEDED must also be set in
GNU_PROPERTY_X86_ISA_1_USED.

4-byte integer value for the x86 instruction set support.

#define GNU_PROPERTY_X86_ISA_1_486           (1U << 0)
#define GNU_PROPERTY_X86_ISA_1_586           (1U << 1)
#define GNU_PROPERTY_X86_ISA_1_686           (1U << 2)
#define GNU_PROPERTY_X86_ISA_1_SSE           (1U << 3)
#define GNU_PROPERTY_X86_ISA_1_SSE2          (1U << 4)
#define GNU_PROPERTY_X86_ISA_1_SSE3          (1U << 5)
#define GNU_PROPERTY_X86_ISA_1_SSSE3         (1U << 6)
#define GNU_PROPERTY_X86_ISA_1_SSE4_1        (1U << 7)
#define GNU_PROPERTY_X86_ISA_1_SSE4_2        (1U << 8)
#define GNU_PROPERTY_X86_ISA_1_AVX           (1U << 9)
#define GNU_PROPERTY_X86_ISA_1_AVX2          (1U << 10)
#define GNU_PROPERTY_X86_ISA_1_AVX512F       (1U << 11)
#define GNU_PROPERTY_X86_ISA_1_AVX512CD      (1U << 12)
#define GNU_PROPERTY_X86_ISA_1_AVX512ER      (1U << 13)
#define GNU_PROPERTY_X86_ISA_1_AVX512PF      (1U << 14)
#define GNU_PROPERTY_X86_ISA_1_AVX512VL      (1U << 15)
#define GNU_PROPERTY_X86_ISA_1_AVX512DQ      (1U << 16)
#define GNU_PROPERTY_X86_ISA_1_AVX512BW      (1U << 17)
#define GNU_PROPERTY_X86_ISA_1_ENDBR         (1U << 18)

Re: RFC: Program Properties

[Carlos O'Donell]

On 10/12/2016 02:03 PM, H.J. Lu wrote:
> There are cases where linker and run-time loader need more information
> about ELF objects beyond what the current gABI provides:

I like the idea. Nick Clifton and I were discussing this at GNU Cauldron 2016.

I appreciate you have come up with some concrete examples, but I think we
need to take these example and flesh them out completely and see if we have
any problems with your proposed model. Can you pick one of the examples and
flesh out how the bits move from the compiler to assembler to static linker
to dynamic linker and what happens then?

To kick off that discussion I have questions that range from the compiler
to the dynamic loader:

(1) How coarse or how fine do you see this checking happening? The current object
you propose, Elf_Prop, is very generic. Could we model more and make life easier
for consumers?

(2) Can you have one ore more pr_type Elf_Prop's in the single object?

(3) Can we use Elf_Prop's to mark per-function properties by expressing the function
to be described in pr_data? Perhaps using dwarf? Again, could we model more to
make consumer's simpler to write?

(4) How do we deal with data-dependent executions that are known to use only
a subset of the shared object features? For example consider code which doesn't use 
IFUNCs but instead checks the CPU type, and conditionally executes code, such a
function would be automatically marked as *_NEEDED for all the relevant ISAs, 
when it's not true and works today. Do we need to define compiler function attributes
to allow users to change or override the program properties e.g. allow the user
to specify the properties exaclty, disabling automatic generation?

(5) I assume the merging of the notes is dependent on the pr_type and has to have
custom code for that merging?

(6) Is there any historical implementations of anything like this?

-- 
Cheers,
Carlos.

Re: RFC: Program Properties

[Jose E. Marchesi]

    >     > 1. Minimum ISAs.  Executables and shared objects, which are optimized
    >     > specifically to run on a particular processor, will not run on processors
    >     > which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
    >     > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
    >     > information to tell if an executable or a shared object is compatible
    >     > with available ISAs.
    >
    >     Why cant the following be defined as processor specific e_flags (like
    >     other processors do) in elf.h itself?
    >
    > It is easy to exhaust the space of EF_* flags.  In sparc this happened
    > many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS
    > and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities.
    
    Hmm. Looks reasonable. But I still have some points to ponder:
    
    e_flags is processor specific and I thought each processor has its own
    space. And e_flags is also 4 byte size (purpose is unsigned integer).
    
    The proposed numbering scheme is already at 17 and 14 more left-shifts
    left. It would be same as e_flags capacity.

In SPARC we have more than 32 hardware capabilities, that can be
combined in any way, so 4 bytes are not enough.

Also, the only practical way to define a "minimum ISA" is through these
hardware capabilities: the sparc specs and implementations are not
linear.  As a result the ordered opcodes architectures we define in
opcodes (that correspond to ISAs in our case) are rather artificial.
Consider for example the `v9v' opcodes architecture:

v9v: V9 with OSA2011 and T4 additions, integer multiply and Fujitsu fp
     multiply-add.

Where OSA2011 (Oracle SPARC Architecture 2011) is an extension to
SPARC-V9 (a spec) and "T4 additions" refer to the T4 extensions to
OSA2011, plus a bunch of specific instructions (integer multiply and the
FJ floating-point multiply-add).

So yes, at least in sparc we need to live with many many hardware
capabilities, and these capabilities are only increasing with the
introduction of new versions of the spec and processors.

Re: RFC: Program Properties

[Maciej W. Rozycki]

On Mon, 17 Oct 2016, H.J. Lu wrote:

> > 4. A reject flag: if such annotated the ABI flag requires explicit support
> >    (special handling beyond the three variants above) and linking fails if
> >    it is set in any input object and the linker does know this ABI flag.
> 
> "reject" isn't very clear.  Is "mandatory" better?

 Such property seen by the component addressed (be it the static linker, 
dynamic loader or OS kernel) would cause the binary to be rejected unless 
already explicitly recognised by the component.  Or IOW unknown such 
properties would be rejected and known ones handled as required.  Hence 
the name proposed.

 That written, having thought about it some more, I think we don't 
actually need such an explicit flag as I think we can reasonably set this 
semantics as the default.  That is any unknown property *not* annotated 
with one of the known flags would be rejected, making an explicit "reject" 
flag redundant.

> > Such annotation would of course have to be consistent across input files.
> >
> >  Such ABI flag flags would allow ABIs to define new ABI flags processed
> > automatically in static linking without the need to upgrade the linker
> > each time a flag is added.
> >
> >  Thoughts?
> 
> Property values can be divided into ranges of different rules, including
> rules which differ from above.

 I'm not sure defining fixed ranges has an advantage over using property 
annotation.  I think it's hard to assess beforehand how many values we may 
need in each range and if we make a range allocated too narrow, then we 
risk running out of entries within, whereas if we make one too broad, then 
we risk running out of the allocation space.  On the other hand by using 
explicit property annotation we will only have consumed as much of the 
allocation space as has actually been defined at any point in time.

 Have I missed anything?

  Maciej

Re: RFC: Program Properties

[Suprateeka R Hegde]

On 13-Oct-2016 11:38 PM, Jose E. Marchesi wrote:
>
>
>     >     > 1. Minimum ISAs.  Executables and shared objects, which are optimized
>     >     > specifically to run on a particular processor, will not run on processors
>     >     > which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
>     >     > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
>     >     > information to tell if an executable or a shared object is compatible
>     >     > with available ISAs.
>     >
>     >     Why cant the following be defined as processor specific e_flags (like
>     >     other processors do) in elf.h itself?
>     >
>     > It is easy to exhaust the space of EF_* flags.  In sparc this happened
>     > many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS
>     > and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities.
>
>     Hmm. Looks reasonable. But I still have some points to ponder:
>
>     e_flags is processor specific and I thought each processor has its own
>     space. And e_flags is also 4 byte size (purpose is unsigned integer).
>
>     The proposed numbering scheme is already at 17 and 14 more left-shifts
>     left. It would be same as e_flags capacity.
>
> In SPARC we have more than 32 hardware capabilities, that can be
> combined in any way, so 4 bytes are not enough.

Ah! Thats the key here. Combination is possible. So you need unique bit 
positions.

And the case is true here too. The following is valid as per the proposal:

GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_ISA_1_486 | 
GNU_PROPERTY_X86_ISA_1_686

Then we may soon need more bits.

On 14-Oct-2016 07:54 AM, Carlos O'Donell wrote:
> To kick off that discussion I have questions that range from the compiler
> to the dynamic loader:

We may want to propagate this to package managers to enforce minimum 
ISA. If the machine does not support minimum ISA, then do not install or 
issue warning.

And then propagate this to archive libraries too. For instance, allow an 
archive library to contain two foo.o files one built with minimum ISA-1 
and another built with minimum ISA-2. And depending on the main 
program's minimum ISA, let the linker pick the right one.

And there are two parts in case of hardware capabilities. One that is 
recorded in the ELF. And the other, the actual one (machine) where this 
ELF runs. Is the loader going to check actual hardware using cpuid? Or 
do we want to propagate this proposal to the kernel also and keep the 
actual hardware capabilities in the ELF image of the kernel (may not 
work with a UEFI based kernel) ?

Its better we discuss as many use cases as possible (as you said) and 
make relevant changes in the design right now.

> (6) Is there any historical implementations of anything like this?

On HP-UX (both on PA-RISC and Intel Itanium) we have similar things. We 
also have a tool called "chatr" (stands for CHange program ATtRibutes) 
that can be used to change program attributes post build.

--
Supra