On 01/16/2017 09:37 AM, Nick Clifton wrote: > Hi H.J. > >> We have 2 different proposals for program properties. Mine: >> >> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html >> >> 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. Comments: (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? -- Cheers, Carlos. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
