[gABI] RFC: Add PT_PROPERTIES/SHF_PROPERTIES

[H.J. Lu]

Hi,

Here is a proposal to add PT_PROPERTIES/SHF_PROPERTIES to gABI.
Any comments?

Thanks.

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

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.properties SHT_NOTE SHF_ALLOC+SHF_PROPERTIES

#define SHF_PROPERTIES 0x00001000

The array elements specify properties of the object. Each 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:

tyepdef 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.

Types of program properties

#define NT_PROPERTIES_LOOS 0x80000000
#define NT_PROPERTIES_HIOS 0xbfffffff
#define NT_PROPERTIES_LOPROC 0xc0000000
#define NT_PROPERTIES_HIPROC 0xdfffffff
#define NT_PROPERTIES_LOUSER 0xe0000000
#define NT_PROPERTIES_HIUSER 0xffffffff

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

#define PT_PROPERTIES 8

Program header should contain only one PT_PROPERTIES segment, which
contains a .note.properties section of an array of properties for
run-time loader and linker.

Proposed properties

#define NT_PROPERTIES_STACK_SIZE 1

Integer value for minimum stack size.

#define NT_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_PROPERTIES_PROVIDED_LIBRARY 3

String of the required 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_PROPERTIES_REQUIRED_LIBRARY or NT_PROPERTIES_PROVIDED_LIBRARY
have the same NAMESPEC, but different SONAMEs.
2. NAMESPEC in any NT_PROPERTIES_REQUIRED_LIBRARY matches an input
libNAMESPEC.so which has different DT_SONAME from SONAME.

#define NT_PROPERTIES_X86_ISA_1 0xc0000000

Integer value for the x86 instruction set support.

#define NT_PROPERTIES_X86_ISA_1_486 (1U << 1)
#define NT_PROPERTIES_X86_ISA_1_586 (1U << 2)
#define NT_PROPERTIES_X86_ISA_1_686 (1U << 3)
#define NT_PROPERTIES_X86_ISA_1_SSE (1U << 4)
#define NT_PROPERTIES_X86_ISA_1_SSE2 (1U << 5)
#define NT_PROPERTIES_X86_ISA_1_SSE3 (1U << 6)
#define NT_PROPERTIES_X86_ISA_1_SSSE3 (1U << 7)
#define NT_PROPERTIES_X86_ISA_1_SSE4_1 (1U << 8)
#define NT_PROPERTIES_X86_ISA_1_SSE4_2 (1U << 9)
#define NT_PROPERTIES_X86_ISA_1_AVX (1U << 10)
#define NT_PROPERTIES_X86_ISA_1_AVX2 (1U << 11)
#define NT_PROPERTIES_X86_ISA_1_AVX512F (1U << 12)
#define NT_PROPERTIES_X86_ISA_1_AVX512CD (1U << 13)
#define NT_PROPERTIES_X86_ISA_1_AVX512ER (1U << 14)
#define NT_PROPERTIES_X86_ISA_1_AVX512PF (1U << 15)
#define NT_PROPERTIES_X86_ISA_1_AVX512VL (1U << 16)
#define NT_PROPERTIES_X86_ISA_1_AVX512DQ (1U << 17)
#define NT_PROPERTIES_X86_ISA_1_AVX512BW (1U << 18)

#define NT_PROPERTIES_X86_ISA_NEEDED (1U << 0)

A bit in the value of the NT_PROPERTIES_X86_ISA_1 entry for the x86
instruction set support. If it is set, the x86 instruction sets of
the corresponding bits must be supported by the hardware. Otherwise,
the hardware support is optional.

#define NT_PROPERTIES_GCC_OPTIONS 0x80000000

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

[Ali Bahrami]

On 01/20/16 10:52, H.J. Lu wrote:
> Hi,
>
> Here is a proposal to add PT_PROPERTIES/SHF_PROPERTIES to gABI.
> Any comments?
>
> Thanks.
>

Hi H.J.,

This proposal has a large amount of overlap with
our existing Solaris Capabilities mechanism, which we've
had in place since 2003, and which first shipped with
Solaris 10. For us, PT_PROPERTIES/SHF_PROPERTIES are not
good gABI candidates, as much as we appreciate that you
took the time and effort to propose one.

Since then, we've extended our model with what we call
"symbol capabilities", in which the capabilities given
on a per-symbol basis to provide multiple implementations
for things like memcpy, allowing the runtime linker to pick
the best one at runtime. Symbol capabilities have some overlap
with the abilities that GNU use STT_GNU_IFUNC for. You may
recall Ulrich proposing STT_IFUNC years ago, but we asked that
it instead be a GNU-ABI feature? That was because of the
conceptual overlap with symbol capabilities, and I think we
have the same issue now.

I think that PT_PROPERTIES/SHF_PROPERTIES would be better
as GNU-only features, PT_GNU_PROPERTIES and SHF_GNU_PROPERTIES.
We're very far down the road with our capabilities infrastructure,
and are very happy with it. It would be a serious problem for
us if the gABI required us to change course now, or to support
duplicate functionality via a second mechanism.

Information on the Solaris features are available online
in the Solaris 11.3 Linker and Libraries Guide:

https://docs.oracle.com/cd/E53394_01/html/E54813/index.html

Chapter 7 contains quite a bit of material on the concepts
and user level functionality:

https://docs.oracle.com/cd/E53394_01/html/E54813/man-cp.html#scrolltoc

And Chapter 13 (Object File Format) describes the ELF details:

https://docs.oracle.com/cd/E53394_01/html/E54813/chapter7-28.html#scrolltoc

Thanks...

- Ali

[Rod Evans]

And in a nutshell:

https://blogs.oracle.com/rie/entry/symbol_capabilities

Information on the Solaris features are available online
in the Solaris 11.3  Linker and Libraries Guide:

    https://docs.oracle.com/cd/E53394_01/html/E54813/index.html

Chapter 7 contains quite a bit of material on the concepts
and user level functionality:

    https://docs.oracle.com/cd/E53394_01/html/E54813/man-cp.html#scrolltoc

And Chapter 13 (Object File Format) describes the ELF details:

    https://docs.oracle.com/cd/E53394_01/html/E54813/chapter7-28.html#scrolltoc

----
Rod.

[Suprateeka R Hegde]

Hi H.J.,

I always want to see gABI supporting newer technologies with new
standards that drive better quality.

I have some comments, however. I have written my opinion after all the
comments.

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

This closely matches with what I posted on x86-64 psABI:
https://goo.gl/JgtzGw

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

On HP-UX we keep this sort of information in .note which later goes into
PT_NOTE. Also, there are APIs available that can be used within the
application to set the size.

> 3. Additional linking command line options embedded in relocatable object
> files:
> a. Additional libraries should be linked in when creating executable
> or shared object.

This looks like belonging to Department-Of-Makefile. I cannot think of a
industrial use-case other than unit-testing where compiler is directly
invoked.

And if we really want to automate, then we need to push lots of
information like library link order (to ensure right symbol resolution).
And may more issues.

> http://sourceware.org/bugzilla/show_bug.cgi?id=12485
> b. Additional compiler command line options are needed to properly
> link LTO objects.

On HP-UX we have IELF (Intermediate ELF) which is similar to LTO
technology. This IELF uses OS specific extensions of gABI to store this
info.

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

We have function level and library level versioning.

> 3. There is no program segment for GNU attributes in executables and
> shared objects.

This is a common problem. On HP-UX we have a tool called fastbind(1)
that is similar to prelink/prebind tool. And for this, we use
PT_HP_FASTBIND. Matches with what Ali commented -- Create PT_GNU_*.

Opinion:
--------
1. Why I mentioned all these is because I wanted to tell that the
industry has solved these problems in custom ways through ELF extensions.

2. Mandating anything new in gABI requires a lot of effort. We can
however keep these enhancements as optional.

3. At the same time, as I said in the beginning, I want to see gABI
evolving to cater to new technologies. And that is why I mentioned
(here: https://goo.gl/cUvLMr) that gABI should also have versions like
DWARF standard specs. These enhancements to fulfill newer technologies,
strict semantics to drive quality, etc., should go into the new version.

4. I have more things like this to add. For instance PT_PERSISTENT for
new age apps that use NVM.

5. Considering all these, I feel it is no more "System V" age. We
definitely need new standards for collaboration and compatibility across
industry.

To Summarize:
-------------
I agree with Ali. Making this a requirement in gABI is very difficult.
Optional is fine, GNU specific is fine, or a new version of gABI
probably under Linux Standard Base (LSB) is a good approach.

--
Supra

[H.J. Lu]

On Fri, Jan 22, 2016 at 10:55 AM, Suprateeka R Hegde

> To Summarize:
> -------------
> I agree with Ali. Making this a requirement in gABI is very difficult.
> Optional is fine, GNU specific is fine, or a new version of gABI probably
> under Linux Standard Base (LSB) is a good approach.
>

Thanks for all feedbacks. I will make those as Linux extensions.

--
H.J.