On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote: > > I think they should simply try to not register LDPT_GET_SYMBOLS or > > LDPT_GET_SYMBOLS_V2 with the plugin in the onload hook and if > > that fails they will know the plugin doesn't support V3 only. I suppose > > it should work to call onload() multiple times (when only increasing the > > set of supported functions) until it returns LDPS_OK without intermediately > > dlclosing it (maybe call cleanup_handler inbertween). This should work > > for old plugin versions. > > > > That said, a better API extension compared to adding some random > > symbol like you propose is to enhance the return value from onload(), > > maybe returning an alternate transfer vector specifying symbol entries > > that will not be used (or return a transfer vector that will be used). > > We've been mostly versioning the symbol related hooks here. > > > > That said, I do not like at all this proposed add of a special symbol > > to flag exclusive v3 use. That's a hack and not extensible at all. > > Speaking of which, onload_v2 would be in order and should possibly > return some instantiation handle of the plugin that the linker could > instruct the plugin to dispose (reset ()?). I see the GCC implementation > of the plugin just has a single global state and it doesn't seem that it's > prepared for multiple onload() calls (but it might work by accident if > you never remove things from the support vector but only add). > > Without revamping the whole API onload_v2 could set the current > global state for the plugin based on the transfer vector and the reset() > API would discard the state (might also be redundant and implicitely > performed by the next onload_v2 call). > > onload_v2 could then also have an "output" transfer vector where the > plugin simply copies the entries it picked and dropped those it will > never call. We'd document the plugin may only pick _one_ of the versioned > API variants. > > That said, the heuristic outlined above might still work with the present > onload() API and existing implementations.
Feels a bit weird to ask, but before entertaining such an API extension, can we step back and understand the v3 variant of get_symbols? It is not documented, and from what little I saw I did not get the "motivation" for its existence (what it is doing that couldn't be done with the v2 api). To me lack of documentation looks like a serious issue :/ Likewise, I don't really understand why mold cannot be flexible and efficiently service both the v2 and v3 variants without committing to one of those in advance. Alexander
