Re: RFC: Program Properties

["Maciej W. Rozycki" <macro@imgtec.com>]

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