This is the mail archive of the
mailing list for the binutils project.
Re: RFH: Annotating ELF binaries
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, "Kirill A. Shutemov" <kirill dot shutemov at linux dot intel dot com>, Tristan Gingold <gingold at adacore dot com>, libc-help at sourceware dot org, Binutils <binutils at sourceware dot org>, devel at lists dot fedoraproject dot org
- Date: Tue, 17 Jan 2017 10:55:20 -0800
- Subject: Re: RFH: Annotating ELF binaries
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <8C6DA8A9-24E4-43DE-8BE9-4A2B3AAC6964@adacore.com> <firstname.lastname@example.org> <CAMe9rOpqhYKZWU5KyqCxkW8QRKVaMEpfHURNQsQuu2iKUg-O5A@mail.gmail.com> <email@example.com> <firstname.lastname@example.org>
On Mon, Jan 16, 2017 at 9:48 AM, Carlos O'Donell <email@example.com> wrote:
> On 01/16/2017 09:37 AM, Nick Clifton wrote:
>> Hi H.J.
>>> We have 2 different proposals for program properties. Mine:
>>> 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.
> (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.