diff mbox series

kbuild: rebuild GCC plugins when the compiler is upgraded

Message ID 20210304113708.215121-1-masahiroy@kernel.org (mailing list archive)
State New, archived
Headers show
Series kbuild: rebuild GCC plugins when the compiler is upgraded | expand

Commit Message

Masahiro Yamada March 4, 2021, 11:37 a.m. UTC
Linus reported a build error due to the GCC plugin incompatibility
when the compiler is upgraded. [1]

  cc1: error: incompatible gcc/plugin versions
  cc1: error: failed to initialize plugin ./scripts/gcc-plugins/stackleak_plugin.so

GCC plugins are tied to a particular GCC version. So, they must be
rebuilt when the compiler is upgraded.

This seems to be a long-standing flaw since the initial support of
GCC plugins.

Extend commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the
compiler is updated"), so that GCC plugins are covered by the
compiler upgrade detection.

[1]: https://lore.kernel.org/lkml/CAHk-=wieoN5ttOy7SnsGwZv+Fni3R6m-Ut=oxih6bbZ28G+4dw@mail.gmail.com/

Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---

 Makefile                         |  1 +
 include/linux/compiler-version.h | 14 ++++++++++++++
 include/linux/kconfig.h          |  2 --
 init/Kconfig                     |  8 ++++----
 scripts/gcc-plugins/Makefile     |  1 +
 5 files changed, 20 insertions(+), 6 deletions(-)
 create mode 100644 include/linux/compiler-version.h

Comments

Kees Cook March 4, 2021, 11:20 p.m. UTC | #1
On Thu, Mar 04, 2021 at 08:37:08PM +0900, Masahiro Yamada wrote:
> Linus reported a build error due to the GCC plugin incompatibility
> when the compiler is upgraded. [1]
> 
>   cc1: error: incompatible gcc/plugin versions
>   cc1: error: failed to initialize plugin ./scripts/gcc-plugins/stackleak_plugin.so
> 
> GCC plugins are tied to a particular GCC version. So, they must be
> rebuilt when the compiler is upgraded.
> 
> This seems to be a long-standing flaw since the initial support of
> GCC plugins.
> 
> Extend commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the
> compiler is updated"), so that GCC plugins are covered by the
> compiler upgrade detection.
> 
> [1]: https://lore.kernel.org/lkml/CAHk-=wieoN5ttOy7SnsGwZv+Fni3R6m-Ut=oxih6bbZ28G+4dw@mail.gmail.com/
> 
> Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This seems fine to me, but I want to make sure Josh has somewhere to
actually go with this. Josh, does this get you any closer? It sounds
like the plugins need to move to another location for packaged kernels?

Reviewed-by: Kees Cook <keescook@chromium.org>
Linus Torvalds March 4, 2021, 11:37 p.m. UTC | #2
On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote:
>
> This seems fine to me, but I want to make sure Josh has somewhere to
> actually go with this. Josh, does this get you any closer? It sounds
> like the plugins need to move to another location for packaged kernels?

Well, it might be worth extending the stuff that gets installed with
/lib/modules/<kernel-version>/ with enough information and
infrastruvcture to then build any external modules.

Yeah, yeah, there's the /boot/config-<kernelversion> thing too, but
honestly, that probably shouldn't have been in /boot to begin with.
That, and the plugins - and possibly any hashes needed for randstruct
etc - might be good to squirrell away in a
/lib/modules/<kernelversion>/build/ subdirectory?

I dunno. I obviously don't build external modules to begin with, much
less with distro kernels...

             Linus
Josh Poimboeuf March 5, 2021, 2:25 a.m. UTC | #3
On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote:
> On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote:
> >
> > This seems fine to me, but I want to make sure Josh has somewhere to
> > actually go with this. Josh, does this get you any closer?

No, this doesn't seem to help me at all.

> > It sounds like the plugins need to move to another location for
> > packaged kernels?
> 
> Well, it might be worth extending the stuff that gets installed with
> /lib/modules/<kernel-version>/ with enough information and
> infrastruvcture to then build any external modules.

The gcc plugins live in scripts/, which get installed by "make
modules_install" already.  So the plugins' source and makefiles are in
/lib/modules/<kernel-version>/build/scripts/gcc-plugins.

So everything needed for building the plugins is already there.  We just
need the kernel makefiles to rebuild the plugins locally, when building
an external module.
Josh Poimboeuf March 6, 2021, 1:28 a.m. UTC | #4
On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote:
> On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote:
> > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > This seems fine to me, but I want to make sure Josh has somewhere to
> > > actually go with this. Josh, does this get you any closer?
> 
> No, this doesn't seem to help me at all.
> 
> > > It sounds like the plugins need to move to another location for
> > > packaged kernels?
> > 
> > Well, it might be worth extending the stuff that gets installed with
> > /lib/modules/<kernel-version>/ with enough information and
> > infrastruvcture to then build any external modules.
> 
> The gcc plugins live in scripts/, which get installed by "make
> modules_install" already.  So the plugins' source and makefiles are in
> /lib/modules/<kernel-version>/build/scripts/gcc-plugins.
> 
> So everything needed for building the plugins is already there.  We just
> need the kernel makefiles to rebuild the plugins locally, when building
> an external module.

This seems to work with very limited testing...  Based on top of
Masahiro's recent patch:

  https://lkml.kernel.org/r/CAK7LNARHoTnZ3gAvHgnYB4n-wYuboxC10A6zURh1ODGhxWd2yA@mail.gmail.com

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] gcc-plugins: Rebuild plugins in external module directory

When building external kernel modules, the build system doesn't require
the GCC version to match the version used to build the original kernel.

In fact, most distros release the compiler and the kernel in separate
packages, with separate release cadences.  So it's not uncommon for
mismatches to occur.

But with GCC plugins enabled, that's no longer allowed:

  cc1: error: incompatible gcc/plugin versions
  cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so

That error comes from the plugin's call to
plugin_default_version_check(), which strictly enforces the GCC version.
The strict check makes sense, because there's nothing to prevent the GCC
plugin ABI from changing, and it often does.

Since plugins are tightly tied to the compiler version, just rebuild
them locally in the external module directory, and then use the local
version in the external module build.

Reported-by: Ondrej Mosnacek <omosnace@redhat.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 Makefile                     | 1 +
 scripts/Makefile.gcc-plugins | 2 +-
 scripts/gcc-plugins/Makefile | 8 ++++++--
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index bc208886fcce..90c6656de224 100644
--- a/Makefile
+++ b/Makefile
@@ -1784,6 +1784,7 @@ prepare:
 		echo "  The kernel was built by: "$(CONFIG_CC_VERSION_TEXT); \
 		echo "  You are using:           $(CC_VERSION_TEXT)"; \
 	fi
+	$(Q)$(MAKE) $(build)=scripts/gcc-plugins
 
 PHONY += help
 help:
diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index 952e46876329..be4303678942 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -48,7 +48,7 @@ export DISABLE_ARM_SSP_PER_TASK_PLUGIN
 
 # All the plugin CFLAGS are collected here in case a build target needs to
 # filter them out of the KBUILD_CFLAGS.
-GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
+GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD),$(objtree))/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
 # The sancov_plugin.so is included via CFLAGS_KCOV, so it is removed here.
 GCC_PLUGINS_CFLAGS := $(filter-out %/sancov_plugin.so, $(GCC_PLUGINS_CFLAGS))
 export GCC_PLUGINS_CFLAGS
diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index b5487cce69e8..9f8e2ef3ab56 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -1,10 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0
 
-$(obj)/randomize_layout_plugin.so: $(objtree)/$(obj)/randomize_layout_seed.h
+ifneq ($(KBUILD_EXTMOD),)
+override obj := $(KBUILD_EXTMOD)/$(obj)
+endif
+
+$(obj)/randomize_layout_plugin.so: $(objtree)/$(src)/randomize_layout_seed.h
 quiet_cmd_create_randomize_layout_seed = GENSEED $@
 cmd_create_randomize_layout_seed = \
   $(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ $(objtree)/include/generated/randomize_layout_hash.h
-$(objtree)/$(obj)/randomize_layout_seed.h: FORCE
+$(objtree)/$(src)/randomize_layout_seed.h: FORCE
 	$(call if_changed,create_randomize_layout_seed)
 targets += randomize_layout_seed.h randomize_layout_hash.h
Masahiro Yamada March 6, 2021, 2:18 a.m. UTC | #5
On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote:
> > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote:
> > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote:
> > > >
> > > > This seems fine to me, but I want to make sure Josh has somewhere to
> > > > actually go with this. Josh, does this get you any closer?
> >
> > No, this doesn't seem to help me at all.
> >
> > > > It sounds like the plugins need to move to another location for
> > > > packaged kernels?
> > >
> > > Well, it might be worth extending the stuff that gets installed with
> > > /lib/modules/<kernel-version>/ with enough information and
> > > infrastruvcture to then build any external modules.
> >
> > The gcc plugins live in scripts/, which get installed by "make
> > modules_install" already.  So the plugins' source and makefiles are in
> > /lib/modules/<kernel-version>/build/scripts/gcc-plugins.
> >
> > So everything needed for building the plugins is already there.  We just
> > need the kernel makefiles to rebuild the plugins locally, when building
> > an external module.
>
> This seems to work with very limited testing...  Based on top of
> Masahiro's recent patch:
>
>   https://lkml.kernel.org/r/CAK7LNARHoTnZ3gAvHgnYB4n-wYuboxC10A6zURh1ODGhxWd2yA@mail.gmail.com




Is this a bad coding contest?

I am not asking you to add ugly ifeq or whatever
hacks to say "this worked for me".

Please feel free to do this in the fedora kernel,
but do not send it to upstream.

Sorry, I really do not want to see hacks like this any more.

Remember, how badly objtool was integrated in the build system,
and you even blocked me from fixing that.







> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH] gcc-plugins: Rebuild plugins in external module directory
>
> When building external kernel modules, the build system doesn't require
> the GCC version to match the version used to build the original kernel.
>
> In fact, most distros release the compiler and the kernel in separate
> packages, with separate release cadences.  So it's not uncommon for
> mismatches to occur.
>
> But with GCC plugins enabled, that's no longer allowed:
>
>   cc1: error: incompatible gcc/plugin versions
>   cc1: error: failed to initialize plugin ./scripts/gcc-plugins/structleak_plugin.so
>
> That error comes from the plugin's call to
> plugin_default_version_check(), which strictly enforces the GCC version.
> The strict check makes sense, because there's nothing to prevent the GCC
> plugin ABI from changing, and it often does.
>
> Since plugins are tightly tied to the compiler version, just rebuild
> them locally in the external module directory, and then use the local
> version in the external module build.
>
> Reported-by: Ondrej Mosnacek <omosnace@redhat.com>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
>  Makefile                     | 1 +
>  scripts/Makefile.gcc-plugins | 2 +-
>  scripts/gcc-plugins/Makefile | 8 ++++++--
>  3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index bc208886fcce..90c6656de224 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1784,6 +1784,7 @@ prepare:
>                 echo "  The kernel was built by: "$(CONFIG_CC_VERSION_TEXT); \
>                 echo "  You are using:           $(CC_VERSION_TEXT)"; \
>         fi
> +       $(Q)$(MAKE) $(build)=scripts/gcc-plugins
>
>  PHONY += help
>  help:
> diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
> index 952e46876329..be4303678942 100644
> --- a/scripts/Makefile.gcc-plugins
> +++ b/scripts/Makefile.gcc-plugins
> @@ -48,7 +48,7 @@ export DISABLE_ARM_SSP_PER_TASK_PLUGIN
>
>  # All the plugin CFLAGS are collected here in case a build target needs to
>  # filter them out of the KBUILD_CFLAGS.
> -GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
> +GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD),$(objtree))/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y))
>  # The sancov_plugin.so is included via CFLAGS_KCOV, so it is removed here.
>  GCC_PLUGINS_CFLAGS := $(filter-out %/sancov_plugin.so, $(GCC_PLUGINS_CFLAGS))
>  export GCC_PLUGINS_CFLAGS
> diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
> index b5487cce69e8..9f8e2ef3ab56 100644
> --- a/scripts/gcc-plugins/Makefile
> +++ b/scripts/gcc-plugins/Makefile
> @@ -1,10 +1,14 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> -$(obj)/randomize_layout_plugin.so: $(objtree)/$(obj)/randomize_layout_seed.h
> +ifneq ($(KBUILD_EXTMOD),)
> +override obj := $(KBUILD_EXTMOD)/$(obj)
> +endif
> +
> +$(obj)/randomize_layout_plugin.so: $(objtree)/$(src)/randomize_layout_seed.h
>  quiet_cmd_create_randomize_layout_seed = GENSEED $@
>  cmd_create_randomize_layout_seed = \
>    $(CONFIG_SHELL) $(srctree)/$(src)/gen-random-seed.sh $@ $(objtree)/include/generated/randomize_layout_hash.h
> -$(objtree)/$(obj)/randomize_layout_seed.h: FORCE
> +$(objtree)/$(src)/randomize_layout_seed.h: FORCE
>         $(call if_changed,create_randomize_layout_seed)
>  targets += randomize_layout_seed.h randomize_layout_hash.h
>
> --
> 2.29.2
>
Josh Poimboeuf March 6, 2021, 2:50 a.m. UTC | #6
On Sat, Mar 06, 2021 at 11:18:31AM +0900, Masahiro Yamada wrote:
> On Sat, Mar 6, 2021 at 10:28 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > On Thu, Mar 04, 2021 at 08:25:00PM -0600, Josh Poimboeuf wrote:
> > > On Thu, Mar 04, 2021 at 03:37:14PM -0800, Linus Torvalds wrote:
> > > > On Thu, Mar 4, 2021 at 3:20 PM Kees Cook <keescook@chromium.org> wrote:
> > > > >
> > > > > This seems fine to me, but I want to make sure Josh has somewhere to
> > > > > actually go with this. Josh, does this get you any closer?
> > >
> > > No, this doesn't seem to help me at all.
> > >
> > > > > It sounds like the plugins need to move to another location for
> > > > > packaged kernels?
> > > >
> > > > Well, it might be worth extending the stuff that gets installed with
> > > > /lib/modules/<kernel-version>/ with enough information and
> > > > infrastruvcture to then build any external modules.
> > >
> > > The gcc plugins live in scripts/, which get installed by "make
> > > modules_install" already.  So the plugins' source and makefiles are in
> > > /lib/modules/<kernel-version>/build/scripts/gcc-plugins.
> > >
> > > So everything needed for building the plugins is already there.  We just
> > > need the kernel makefiles to rebuild the plugins locally, when building
> > > an external module.
> >
> > This seems to work with very limited testing...  Based on top of
> > Masahiro's recent patch:
> >
> >   https://lkml.kernel.org/r/CAK7LNARHoTnZ3gAvHgnYB4n-wYuboxC10A6zURh1ODGhxWd2yA@mail.gmail.com
> 
> Is this a bad coding contest?
> 
> I am not asking you to add ugly ifeq or whatever
> hacks to say "this worked for me".
> 
> Please feel free to do this in the fedora kernel,
> but do not send it to upstream.
> 
> Sorry, I really do not want to see hacks like this any more.

Geez, that's a bit harsh.  I never claimed to be a brilliant makefile
coder.  Do you have any constructive feedback for improving the patch?

> Remember, how badly objtool was integrated in the build system,
> and you even blocked me from fixing that.

I have no idea what you're talking about, nor how it would be relevant
to this patch.
Josh Poimboeuf March 9, 2021, 8:31 p.m. UTC | #7
On Fri, Mar 05, 2021 at 08:50:59PM -0600, Josh Poimboeuf wrote:
> > Is this a bad coding contest?
> > 
> > I am not asking you to add ugly ifeq or whatever
> > hacks to say "this worked for me".
> > 
> > Please feel free to do this in the fedora kernel,
> > but do not send it to upstream.
> > 
> > Sorry, I really do not want to see hacks like this any more.

Masahiro,

Ping.  Do you have a better approach for building GCC plugins in the
external module directory?
Masahiro Yamada March 10, 2021, 1:44 p.m. UTC | #8
On Wed, Mar 10, 2021 at 5:31 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Fri, Mar 05, 2021 at 08:50:59PM -0600, Josh Poimboeuf wrote:
> > > Is this a bad coding contest?
> > >
> > > I am not asking you to add ugly ifeq or whatever
> > > hacks to say "this worked for me".
> > >
> > > Please feel free to do this in the fedora kernel,
> > > but do not send it to upstream.
> > >
> > > Sorry, I really do not want to see hacks like this any more.
>
> Masahiro,
>
> Ping.  Do you have a better approach for building GCC plugins in the
> external module directory?


I am not sure if building GCC plugins in the external module directory
is the right approach.


--
Best Regards
Masahiro Yamada
Josh Poimboeuf March 18, 2021, 5:57 p.m. UTC | #9
On Wed, Mar 10, 2021 at 10:44:46PM +0900, Masahiro Yamada wrote:
> > Masahiro,
> >
> > Ping.  Do you have a better approach for building GCC plugins in the
> > external module directory?
> 
> 
> I am not sure if building GCC plugins in the external module directory
> is the right approach.

I'm certainly open to any better ideas that would allow GCC plugins to
be enabled in distro kernel builds.
diff mbox series

Patch

diff --git a/Makefile b/Makefile
index 44ab0dfd3698..5f66cf5af5f7 100644
--- a/Makefile
+++ b/Makefile
@@ -490,6 +490,7 @@  USERINCLUDE    := \
 		-I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \
 		-I$(srctree)/include/uapi \
 		-I$(objtree)/include/generated/uapi \
+                -include $(srctree)/include/linux/compiler-version.h \
                 -include $(srctree)/include/linux/kconfig.h
 
 # Use LINUXINCLUDE when you must reference the include/ directory.
diff --git a/include/linux/compiler-version.h b/include/linux/compiler-version.h
new file mode 100644
index 000000000000..2b2972c77c62
--- /dev/null
+++ b/include/linux/compiler-version.h
@@ -0,0 +1,14 @@ 
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifdef  __LINUX_COMPILER_VERSION_H
+#error "Please do not include <linux/compiler-version.h>. This is done by the build system."
+#endif
+#define __LINUX_COMPILER_VERSION_H
+
+/*
+ * This header exists to force full rebuild when the compiler is upgraded.
+ *
+ * When fixdep scans this, it will find this string "CONFIG_CC_VERSION_TEXT"
+ * and add dependency on include/config/cc/version/text.h, which is touched
+ * by Kconfig when the version string from the compiler changes.
+ */
diff --git a/include/linux/kconfig.h b/include/linux/kconfig.h
index e78e17a76dc9..24a59cb06963 100644
--- a/include/linux/kconfig.h
+++ b/include/linux/kconfig.h
@@ -2,8 +2,6 @@ 
 #ifndef __LINUX_KCONFIG_H
 #define __LINUX_KCONFIG_H
 
-/* CONFIG_CC_VERSION_TEXT (Do not delete this comment. See help in Kconfig) */
-
 #include <generated/autoconf.h>
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
diff --git a/init/Kconfig b/init/Kconfig
index 0dd44d951e67..b6f641567b7c 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -20,10 +20,10 @@  config CC_VERSION_TEXT
 	    When the compiler is updated, Kconfig will be invoked.
 
 	  - Ensure full rebuild when the compiler is updated
-	    include/linux/kconfig.h contains this option in the comment line so
-	    fixdep adds include/config/cc/version/text.h into the auto-generated
-	    dependency. When the compiler is updated, syncconfig will touch it
-	    and then every file will be rebuilt.
+	    include/linux/compiler-version.h contains this option in the comment
+	    line so fixdep adds include/config/cc/version/text.h into the
+	    auto-generated dependency. When the compiler is updated, syncconfig
+	    will touch it and then every file will be rebuilt.
 
 config CC_IS_GCC
 	def_bool $(success,test "$(cc-name)" = GCC)
diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index b5487cce69e8..1952d3bb80c6 100644
--- a/scripts/gcc-plugins/Makefile
+++ b/scripts/gcc-plugins/Makefile
@@ -22,6 +22,7 @@  always-y += $(GCC_PLUGIN)
 GCC_PLUGINS_DIR = $(shell $(CC) -print-file-name=plugin)
 
 plugin_cxxflags	= -Wp,-MMD,$(depfile) $(KBUILD_HOSTCXXFLAGS) -fPIC \
+		  -include $(srctree)/include/linux/compiler-version.h \
 		   -I $(GCC_PLUGINS_DIR)/include -I $(obj) -std=gnu++11 \
 		   -fno-rtti -fno-exceptions -fasynchronous-unwind-tables \
 		   -ggdb -Wno-narrowing -Wno-unused-variable \