[RFC][PATCH 3/N] lto-plugin: Port to C++

[Andrew Pinski]

On Sun, Jan 9, 2022 at 11:51 PM Richard Biener via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On Wed, Jan 5, 2022 at 2:28 PM Martin Liška <mliska@suse.cz> wrote:
> >
> > Hello.
> >
> > I'm working on some changes that will be needed for support of ld.mold.
> > And I would like to have the plugin in C++. Having that, we can utilize basic
> > contains like std::vector (instead of xrealloc(foo, len + 1)...).
> >
> > I split the patch into 2 pieces where the second one is only result
> > of autoreconf and automake.
> >
> > Lightly tested with ld.bfd, ld.gold and lto.exp.
>
> With the linker plugin build by GCC using its libstdc++ statically(?)
> and for example gold (also a C++ application) built by another
> (GCC) system compiler there might be two different versioned
> libstdc++ in the process image after dlopening the plugin.  Is the
> libstdc++ "copy" in the plugin sufficiently isolated to not cause
> problems here?  Do we need to pay extra care as to the subset
> of the C++ standard library we can use (I'm thinking of parts
> initialized on load time like I/O)?

It should be isolated after r12-3491-g9e58de3ce00fc2385 . One of the
reasons why I did that patch is because
I noticed the lto plugin was exporting some libiberty symbols even.

Though I don't know the interaction between that and GNU_UNIQUE
symbols which could cause issues. Someone would
need to check the symbols on the plugin after this patch to make sure
no symbols have either GNU_UNIQUE on them or
exported.

Thanks,
Andrew Pinski

>
> That said, I'm not sure this is worth the trouble.
>
> Richard.
>
> >
> > Thoughts?
> > Thanks,
> > Martin