Re: RFC: Program Properties

[Carlos O'Donell <carlos@redhat.com>]

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?

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

(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?

(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?

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

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

-- 
Cheers,
Carlos.