This is the mail archive of the
mailing list for the binutils project.
Re: RFH: Annotating ELF binaries
- From: Nick Clifton <nickc at redhat dot com>
- To: "Carlos O'Donell" <carlos 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: Wed, 18 Jan 2017 17:02:23 +0000
- 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>
> I've added 2 questions to the Toolchain/Watermark wiki but will post them
> here for posterity:
Thanks - I'll try answering them here first, and if my answers make sense
then I will update the wiki.
> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what
> you are proposing?
Good question, and unfortunately I do not know the answer. The problem
is, I have been unable to locate any documentation that describes
SHT_GNU_ATTRIBUTES and how it is supposed to be used.
I think that the two schemes are quite similar, although this new proposal
is intended to be able to cope with attributes that only apply to part of
an executable and not necessarily the executable as a whole. (Also, IMHO,
my proposal has better documentation...)
> (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.
I believe that H.J's design for the dynamic link notes does take efficiency
into consideration, but I will leave that for him to comment on further.
One thing that I have already done for the static notes is to implement a
new option for objcopy called "--merge-notes" which eliminates redundancies.
Theoretically this option could be extended to work with the dynamic notes
too, helping to make them as space efficient as possible.
Another possibility is that the linker could be extended so that when it
creates a dynamic executable it also inserts a "master" dynamic linker note,
which contains all of the information that the dynamic linker will need,
without it having to search through all of the shared libraries used by the
application. (This does assume that the shared libraries examined at static
link time are the same ones that are loaded/used at dynamic link time).
> (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.
I think that this might not be easy to do in a way that both imposes a low
code-increase cost on the dynamic linker and a keep-the-dynamic-link-notes-small
space requirement. There is no harm in investigating though.
> 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.
Now this might well be feasible. I am thinking of another new option to objcopy
here that examines the static notes and generates dynamic notes from them. This
should be quite straightforward, provided that the static notes have captures
the right information.