This is the mail archive of the
mailing list for the binutils project.
Re: RFH: Annotating ELF binaries
- From: Carlos O'Donell <carlos at redhat dot com>
- To: Nick Clifton <nickc at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, "Kirill A. Shutemov" <kirill dot shutemov at linux dot intel dot com>
- Cc: 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: Mon, 16 Jan 2017 12:48:06 -0500
- Subject: Re: RFH: Annotating ELF binaries
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <8C6DA8A9-24E4-43DE-8BE9-4A2B3AAC6964@adacore.com> <email@example.com> <CAMe9rOpqhYKZWU5KyqCxkW8QRKVaMEpfHURNQsQuu2iKUg-O5A@mail.gmail.com> <firstname.lastname@example.org>
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
(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?