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 <mli...@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
