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? > >> 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. Martin > > Honza >> >> Richard.
