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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
