Re: RFC: Program Properties

["H.J. Lu" <hjl.tools@gmail.com>]

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.