Re: RFC: Program Properties

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

On Thu, Oct 13, 2016 at 7:24 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 10/12/2016 02:03 PM, H.J. Lu 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 appreciate you have come up with some concrete examples, but I think we
> need to take these example and flesh them out completely and see if we have
> any problems with your proposed model. Can you pick one of the examples and
> flesh out how the bits move from the compiler to assembler to static linker
> to dynamic linker and what happens then?
>
> To kick off that discussion I have questions that range from the compiler
> to the dynamic loader:
>
> (1) How coarse or how fine do you see this checking happening? The current object
> you propose, Elf_Prop, is very generic. Could we model more and make life easier
> for consumers?

The consumers of my proposal are linker and loader.  It provided a way
to describe program properties to them for the whole object file.

> (2) Can you have one ore more pr_type Elf_Prop's in the single object?

A sngle object file has one .note.gnu.property.0 note section which is
an array of Elf_Prop.  If we run out of property types, we can add
another property note section.

> (3) Can we use Elf_Prop's to mark per-function properties by expressing the function
> to be described in pr_data? Perhaps using dwarf? Again, could we model more to
> make consumer's simpler to write?

Program property covers the whole object file, not individual functions.
We can add an auxiliary symbol table for function property.

> (4) How do we deal with data-dependent executions that are known to use only
> a subset of the shared object features? For example consider code which doesn't use
> IFUNCs but instead checks the CPU type, and conditionally executes code, such a
> function would be automatically marked as *_NEEDED for all the relevant ISAs,
> when it's not true and works today. Do we need to define compiler function attributes
> to allow users to change or override the program properties e.g. allow the user
> to specify the properties exaclty, disabling automatic generation?

AVX is marked as needed only if the program won't run without AVX.
In most cases, compiler doesn't know if it is true even when AVX is
generated.  Only developers know that.

> (5) I assume the merging of the notes is dependent on the pr_type and has to have
> custom code for that merging?

That is correct.

> (6) Is there any historical implementations of anything like this?
>

GNU attribute? But it isn't for run-time loader.

-- 
H.J.