Hi Carlos,
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.
Cheers
Nick