[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: Program Properties
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