On Thu, May 5, 2022 at 8:15 AM Richard Biener <richard.guent...@gmail.com> wrote: > > On Wed, May 4, 2022 at 3:31 PM Martin Liška <mli...@suse.cz> wrote: > > > > On 5/4/22 15:10, Alexander Monakov wrote: > > > On Wed, 4 May 2022, Martin Liška wrote: > > > > > >> On 5/4/22 14:32, Alexander Monakov wrote: > > >>> On Wed, 4 May 2022, Martin Liška wrote: > > >>> > > >>>> The patch is a follow-up of the discussion we've got in: > > >>>> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593901.html > > >>>> > > >>>> Mold linker would appreciate knowing in advance if get_symbols_v3 is > > >>>> supported > > >>>> by a GCC plug-in or not. > > > > > > Out of curiousity, I looked at mold, and I don't understand what problem > > > this > > > detection is solving, nor why this is the best way to solve that. Was > > > there > > > some discussion with mold author I should check out? > > > > Sure, please take a look at this issue: > > https://github.com/rui314/mold/issues/454#issuecomment-1116849458 > > > > > > > > Note that mold takes this not only as 'v3 API is supported', but, more > > > importantly, as 'v2 entrypoint will not be called'. > > > > Yes, if they register get_symbols_v3, then it will be called. That's how the > > plug-in works. > > 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. Richard. > Richard. > > > Martin > > > > > > > > Alexander > >
