This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFH: Annotating ELF binaries


On Mon, Jan 16, 2017 at 9:48 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/16/2017 09:37 AM, Nick Clifton wrote:
>> Hi H.J.
>>
>>> We have 2 different proposals for program properties.  Mine:
>>>
>>> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html
>>>
>>> has a much smaller scope.  New features on upcoming Intel platforms,
>>> like 5-level paging, need this extension for loader decision at run-time.
>>> How should we move forward with program property extensions?
>>
>> I would like to combine the two approaches.  Ie use your notes for
>> properties that need to be examined at run-time (specifically the
>> loader, although I imagine that the application itself might be
>> interested in reading its own notes).  Plus use the note scheme I
>> am proposing for static analysis tools.
>>
>> I am currently using a gcc plugin to generate the notes, and I think
>> that this should be extendable to generate your notes as well.  (Using
>> a plugin is advantageous in that it is not tied to the latest gcc release.
>> It can be built to run with older gcc's, and it can be updated
>> independently of the gcc release cycle).
>>
>> What do you think ?
>
> I've added 2 questions to the Toolchain/Watermark wiki but will post them
> here for posterity:
>
> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what
>     you are proposing?
>
> (2) What is being done to ensure the attributes are space and time
>     efficient for dynamic link comparison in the dynamic linker?
>     Speed of checking 10,000 DSOs (scalability) for ABI compatibility is
>     going to be a very important requirement.
>
> Comments:
>
> (a) Ian requests clear separation between language and psABI notes.
>
> Notes are notes. The attribute system should be sufficiently flexible to
> handle both, and the "clear sepration" is just a documentation aspect,
> and still important, but just about writing down what the notes mean in
> clear detail.
>
> (b) Loadable notes and space/time efficiency vs. non-loadable notes and
>     static analysis tools.
>
> Run-time checking of properties is radically different from offline
> checking of properties and we absolutely need two different designs to
> meet these needs. However, if we could weld the two together in a compatible
> way, that would be great. For example if the dynamic loader could map from
> a 'run-time property' to a 'link-time property' to increase the verbosity
> of the error in a failure scenario, then that might be beneficial. If we
> could translate 'link-time notes' into 'a collection of run-time properties' in
> a semi-automatic fashion given strict rules about the notes application,
> then that would also be awesome.
>
> (c) The case against SHT_GNU_ATTRIBUTES (Question 2).
>
> Not used. -- Then we should just use them for x86.
>
> IFUNC complication. -- Any new framework must be able to tolerate that
> a given interface may have a "range" of ABIs it works with, and those
> represent the set of ABIs it can change to. Attributes that don't allow
> sets of values are going to be problematic in the face of IFUNCs.
>
> No loadable segment. -- Correct. They were designed for link-time support only.
>
> Most attributes don't apply to dynamic loading. -- Correct. Space inefficient.
>
> Layout not optimal for loading.  -- Correct. Time/Space inefficient.
>
> In summary SHT_GNU_ATTRIBUTES might not work for run-time properties, but
> what about link-time properties? Why not resuse this framework?
>

My property proposal is an extension of existing .note.ABI-tag and
.note.gnu.build-id notes, which are loaded sections and don't require
SHT_GNU_ATTRIBUTES.  However, it only supports object scope
property, not symbol scope property.  It is sufficient for run-time loader,
but inadequate for static tools.   Should we evaluate 2 approaches as 2
orthogonal ones?  Use loaded note to cover object scope properties and
non-loaded note for symbol scope properties.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]