On Wed, 4 May 2022 15:31:32 +0200 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. FWIW, I usually use an alias to some existing, exported symbol, like: /* Announce that we are GPL. */ #if defined __GNUC__ extern __typeof (plugin_init) plugin_is_GPL_compatible __attribute__ ((alias ("plugin_init"))); #else unsigned char plugin_is_GPL_compatible; #endif
