[RFC,3/N] lto-plugin: Port to C++
Commit Message
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.
Thoughts?
Thanks,
Martin
Comments
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)?
That said, I'm not sure this is worth the trouble.
Richard.
>
> Thoughts?
> Thanks,
> Martin
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
On 1/10/22 08:50, Richard Biener 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)?
Hmm, didn't realize that.
>
> That said, I'm not sure this is worth the trouble.
Agree. That said, I would like to approve patches 1/2 that are
a stage1 material and do a refactoring that worth doing.
What do you think?
Cheers,
Martin
>
> Richard.
>
>>
>> Thoughts?
>> Thanks,
>> Martin
From d3cd968eacecaa9e9feab7b67f9fabb61f81cb51 Mon Sep 17 00:00:00 2001
From: Martin Liska <mliska@suse.cz>
Date: Wed, 5 Jan 2022 14:06:08 +0100
Subject: [PATCH 1/2] Port to CPP.
---
lto-plugin/Makefile.am | 8 ++++----
lto-plugin/configure.ac | 1 +
lto-plugin/{lto-plugin.c => lto-plugin.cc} | 12 ++++++++++++
3 files changed, 17 insertions(+), 4 deletions(-)
rename lto-plugin/{lto-plugin.c => lto-plugin.cc} (99%)
@@ -11,14 +11,14 @@ AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS)
AM_CFLAGS = @ac_lto_plugin_warn_cflags@ $(CET_HOST_FLAGS)
AM_LDFLAGS = @ac_lto_plugin_ldflags@
AM_LIBTOOLFLAGS = --tag=disable-static
-override CFLAGS := $(filter-out -fsanitize=address -fsanitize=hwaddress,$(CFLAGS))
-override LDFLAGS := $(filter-out -fsanitize=address -fsanitize=hwaddress,$(LDFLAGS))
+override CXXFLAGS := $(filter-out -fsanitize=address -fsanitize=hwaddress,$(CXXFLAGS))
+override LDFLAGS := $(filter-out -fsanitize=address -fsanitize=hwaddress,$(LDFLAGS)) -lstdc++
libexecsub_LTLIBRARIES = liblto_plugin.la
gcc_build_dir = @gcc_build_dir@
in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), $(gcc_build_dir)/$(lib))
-liblto_plugin_la_SOURCES = lto-plugin.c
+liblto_plugin_la_SOURCES = lto-plugin.cc
# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) \
$(lt_host_flags) -module -avoid-version -bindir $(libexecsubdir) \
@@ -39,7 +39,7 @@ liblto_plugin_la_DEPENDENCIES = \
$(if $(wildcard $(libiberty_pic)),$(libiberty_pic),))
LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
liblto_plugin_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
- $(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
+ $(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CFLAGS) $(CFLAGS) \
$(liblto_plugin_la_LDFLAGS) $(LTLDFLAGS) -o $@
all-local: $(in_gcc_libs)
@@ -10,6 +10,7 @@ AC_ARG_WITH(libiberty,
AC_SUBST(with_libiberty)
AC_USE_SYSTEM_EXTENSIONS
AC_PROG_CC
+AC_PROG_CXX
AC_SYS_LARGEFILE
ACX_PROG_CC_WARNING_OPTS([-Wall], [ac_lto_plugin_warn_cflags])
similarity index 99%
rename from lto-plugin/lto-plugin.c
rename to lto-plugin/lto-plugin.cc
@@ -64,7 +64,11 @@ along with this program; see the file COPYING3. If not see
#ifndef WEXITSTATUS
#define WEXITSTATUS(S) (((S) & 0xff00) >> 8)
#endif
+
+/* Defined in string.h */
+#define HAVE_DECL_BASENAME 1
#include <libiberty.h>
+
#include <hashtab.h>
#include "../gcc/lto/common.h"
#include "simple-object.h"
@@ -1368,6 +1372,10 @@ process_option (const char *option)
verbose = verbose || debug;
}
+#ifdef __cplusplus
+extern "C" {
+#endif
+
/* Called by gold after loading the plugin. TV is the transfer vector. */
enum ld_plugin_status
@@ -1540,3 +1548,7 @@ onload (struct ld_plugin_tv *tv)
return LDPS_OK;
}
+
+#ifdef __cplusplus
+}
+#endif
--
2.34.1