On Mon, May 16, 2022 at 11:50 AM Jan Hubicka <hubi...@kam.mff.cuni.cz> wrote: > > > On 5/16/22 11:25, Jan Hubicka via Gcc-patches wrote: > > >> > > >> Sure having a 'plugin was compiled from sources of the GCC N.M compiler' > > >> is useful if bugs are discovered in old versions that you by definition > > >> cannot > > >> fix but can apply workarounds to. Note the actual compiler used might > > >> still > > >> differ. Note that still isn't clean API documentation / extension of > > >> the plugin > > >> API itself. As of thread safety we can either add a claim_file_v2_hook > > >> or try to do broader-level versioning of the API with a new api_version > > >> hook which could also specify that with say version 2 the plugin will > > >> not use get_symbols_v2 but only newer, etc. The linker would announce > > >> the API version it likes to use and the plugin would return the > > >> (closest) version > > >> it can handle. A v2 could then also specify that claim_file needs to be > > > > > > Yep, I think having the API version handshake is quite reasonable way to > > > go as the _v2,_v3 symbols seems already getting bit out of hand and we > > > essentially have 3 revisions of API to think of > > > (first adding LDPR_PREVAILING_DEF_IRONLY_EXP, second adding > > > GET_SYMBOLS_V3 and now we plan third adding thread safety and solving > > > the file handler problems) > > > > How should be design such a version handshake? > > As richi outlined. We need to assign version number of the API (with 1, > 2, 3 defind to match existing revisions) and define version 4 which will > have have way for plugin to announce maximal api version supported and > linker telling plugin what API version it wants to work with. That > shold be min(linker_api, plugin_api) > > Since revisions happens relatively rarely, I think we should be able to > stay with single number determining it. > > > > > > > >> thread safe, or that cleanup should allow a followup onload again with > > >> a state identical to after dlopen, etc. > > >> > > >> Is there an API document besides the header itself somewhere? > > > > > > There is https://gcc.gnu.org/wiki/whopr/driver > > > I wonder if this can't be moved into more official looking place since > > > it looks like it is internal to GCC WHOPR implementation this way. > > > > We can likely add it here: > > https://gcc.gnu.org/onlinedocs/gccint/LTO.html#LTO > > > > What do you think? I can port it. > > I am bit worried that it is place LLVM developers will not look at > since name "GCC internals" suggests it is internal to GCC. It is > not. However perhaps we can link it from binutils docs, plugin header > and gcc plugin source to make it hopefully obvious enough. Maybe > binutils docs would be an alternative. Yet we want other linkers support > it: I am really happy mold now supports plugin API, but if lld and MacOS > linker had it it would make our life easier.
Yep. Or if the docs are not too extensive pasting them into plugin-api.h itself might be not the worst idea either ... basically provide markup that doxygen or similar tools can re-create sth like the wiki page? Richard. > Honza > > > > Martin > > > > > > > > Honza > > >> > > >> Richard. > >
