> > 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) > 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. Honza > > Richard.
