public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Suprateeka R Hegde <hegdesmailbox@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>, gnu-gabi@sourceware.org
Subject: Re: RFC: Program Properties
Date: Fri, 01 Jan 2016 00:00:00 -0000	[thread overview]
Message-ID: <56FD5389.9000805@gmail.com> (raw)
In-Reply-To: <CAMe9rOp=TUY6WtPB+-g9Cv-yv8nrSw+JJT5+0rYff0+vZEwFXg@mail.gmail.com>

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)
>

  reply	other threads:[~2016-03-31 16:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-01  0:00 H.J. Lu
2016-01-01  0:00 ` Suprateeka R Hegde [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-01-01  0:00 H.J. Lu
2016-01-01  0:00 H.J. Lu
2016-01-01  0:00 ` Carlos O'Donell
2016-01-01  0:00   ` H.J. Lu
2016-01-01  0:00   ` Maciej W. Rozycki
2016-01-01  0:00     ` H.J. Lu
2016-01-01  0:00       ` Nick Clifton
2016-01-01  0:00         ` H.J. Lu
2016-01-01  0:00           ` Suprateeka R Hegde
2016-01-01  0:00       ` Maciej W. Rozycki
2016-01-01  0:00         ` H.J. Lu
2016-01-01  0:00           ` H.J. Lu
2016-01-01  0:00 ` Suprateeka R Hegde
2016-01-01  0:00   ` Jose E. Marchesi
2016-01-01  0:00     ` Suprateeka R Hegde
2016-01-01  0:00       ` Jose E. Marchesi
2016-01-01  0:00         ` Suprateeka R Hegde
2016-01-01  0:00           ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56FD5389.9000805@gmail.com \
    --to=hegdesmailbox@gmail.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=hjl.tools@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).