| Message ID | 20220815013317.26121-1-dmitrii.bundin.a@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] kbuild: add debug level and macro defs options | expand |
On Mon, Aug 15, 2022 at 10:34 AM Dmitrii Bundin <dmitrii.bundin.a@gmail.com> wrote: > > Adds config options to control debug info level and producing of macro > definitions for GCC/Clang. > > Option DEBUG_INFO_LEVEL is responsible for controlling debug info level. > Before GCC 11 and Clang 12 -gsplit-dwarf implicitly uses -g2. To provide > a way to override the setting with, e.g. -g1, DEBUG_INFO_LEVEL is set > independently from DEBUG_INFO_SPLIT. > > Option DEBUG_MACRO_DEFINITIONS is responsible for controlling inclusion > of macro definitions. Since Clang uses -fdebug-macro to control if macro > definitions are produced which is different from GCC, provides a > compiler-specific way of handling macro inclusion. The option is handled > after DEBUG_INFO_LEVEL since -g3 -g2 implies -g2, but -g2 -g3 implies > -g3 and GCC uses -g3 to produce macro definitions. I am not sure if DEBUG_INFO_LEVEL is useful because the macro debug data is now enabled by DEBUG_MACRO_DEFINITIONS. -g1 is only possible via DEBUG_INFO_LEVEL, but presumably it is not your main interest (and not sure if there is anybody interested) because the main motivation for your v1 is to generate macro debug data. BTW, DEBUG_INFO_MACRO might be more consistent (as the others are prefixed DEBUG_INFO_*), but that might be just my personal preference. > > Signed-off-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com> > --- > > Changes in v2: https://lore.kernel.org/all/20220804223504.4739-1-dmitrii.bundin.a@gmail.com/ > - Replace hardcoded -g3 with a configurable debug info level > > Changes in v3: https://lore.kernel.org/all/20220814002021.16990-1-dmitrii.bundin.a@gmail.com/ > - Make -g<level> and -gdwarf-split to be set independently > - Add a separate option to control macro definitions for GCC/Clang > > lib/Kconfig.debug | 20 ++++++++++++++++++++ > scripts/Makefile.debug | 12 ++++++++++-- > 2 files changed, 30 insertions(+), 2 deletions(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 2e24db4bff19..ace6f2eddb56 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -304,6 +304,26 @@ config DEBUG_INFO_REDUCED > DEBUG_INFO build and compile times are reduced too. > Only works with newer gcc versions. > > +config DEBUG_INFO_LEVEL > + int "Debug info level" > + range 1 3 > + default "2" > + help > + Sets the level of how much debug information to generate (-glevel). > + Level 1 produces minimal debug information without including information > + about local variables. Level 3 includes extra information like macro > + definitions. Setting up level 3 will require significantly more disk > + space and increase built time. > + > +config DEBUG_MACRO_DEFINITIONS > + bool "Add macro definitions to debug info" > + default n > + help > + Generates macro definitions to provide a way to expand macros right > + in the debugging session. This information can be used with macro expand, > + info macro in gdb. This option is equivalent to setting -g3 in GCC and > + -fdebug-macro in Clang. > + > config DEBUG_INFO_COMPRESSED > bool "Compressed debugging information" > depends on $(cc-option,-gz=zlib) > diff --git a/scripts/Makefile.debug b/scripts/Makefile.debug > index 9f39b0130551..29cd04234e75 100644 > --- a/scripts/Makefile.debug > +++ b/scripts/Makefile.debug > @@ -2,8 +2,6 @@ DEBUG_CFLAGS := > > ifdef CONFIG_DEBUG_INFO_SPLIT > DEBUG_CFLAGS += -gsplit-dwarf > -else > -DEBUG_CFLAGS += -g > endif > > ifndef CONFIG_AS_IS_LLVM > @@ -16,6 +14,16 @@ dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5 > DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) > endif > > +DEBUG_CFLAGS += -g$(CONFIG_DEBUG_INFO_LEVEL) > +ifdef CONFIG_DEBUG_MACRO_DEFINITIONS > +ifdef CONFIG_CC_IS_GCC > +DEBUG_CFLAGS += -g3 > +endif > +ifdef CONFIG_CC_IS_CLANG > +DEBUG_CFLAGS += -fdebug-macro > +endif > +endif > + > ifdef CONFIG_DEBUG_INFO_REDUCED > DEBUG_CFLAGS += -fno-var-tracking > ifdef CONFIG_CC_IS_GCC > -- > 2.17.1 > -- Best Regards Masahiro Yamada
On Thu, Aug 18, 2022 at 7:14 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > -g1 is only possible via DEBUG_INFO_LEVEL, but > presumably it is not your main interest > (and not sure if there is anybody interested) > because the main motivation for your v1 > is to generate macro debug data. I tested the build process with -g1 and it turned out to generate an image that is 20% lesser in size. This is indeed not really my use-case, but are you sure it might not be helpful in general? The reason to add DEBUG_INFO_LEVEL was also motivated by the GCC11+/Clang12+ behavior of -gsplit-dwarf to provide an orthogonal debug level config. "The later -g<level> wins" behavior in turns works identically for both older and newer compiler versions so such an implementation provides version independent build behavior. Testing on gcc-11, -gdwarf-<level>/-gdwarf still implies -g2. It seemed a clearer way to me to explicitly set a debug level that just wins instead of relying on implicits. Regards Dmitrii
On Sun, Aug 14, 2022 at 6:34 PM Dmitrii Bundin <dmitrii.bundin.a@gmail.com> wrote: > > Adds config options to control debug info level and producing of macro > definitions for GCC/Clang. > > Option DEBUG_INFO_LEVEL is responsible for controlling debug info level. > Before GCC 11 and Clang 12 -gsplit-dwarf implicitly uses -g2. To provide > a way to override the setting with, e.g. -g1, DEBUG_INFO_LEVEL is set > independently from DEBUG_INFO_SPLIT. > > Option DEBUG_MACRO_DEFINITIONS is responsible for controlling inclusion > of macro definitions. Since Clang uses -fdebug-macro to control if macro > definitions are produced which is different from GCC, provides a > compiler-specific way of handling macro inclusion. The option is handled > after DEBUG_INFO_LEVEL since -g3 -g2 implies -g2, but -g2 -g3 implies > -g3 and GCC uses -g3 to produce macro definitions. > > Signed-off-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com> > --- > > Changes in v2: https://lore.kernel.org/all/20220804223504.4739-1-dmitrii.bundin.a@gmail.com/ Is any of this really necessary? It seems like a great way to bloat vmlinux artifacts built with CONFIG_DEBUG_INFO even further. The above link mentions "when debugging with GDB." In that case, please don't add new Kconfigs for these; just set -g3 when CONFIG_GDB_SCRIPTS=y.
On Fri, Aug 19, 2022 at 8:42 PM Nick Desaulniers <ndesaulniers@google.com> wrote: > > Is any of this really necessary? Consider the case if CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y. Prior to GCC11/Clang12 -gsplit-dwarf implied -g2. So on newer compilers with -gsplit-dwarf in use there would be no debug symbols produced. -gdwarf-4/5 still implies -g2, but in case CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y neither of the options are set. So it seems like a reasonable choice to provide a debug info level config that would explicitly set the level without relying on implicits. The default value of the config is set to -g2 to not change the build behavior that was before introducing the option. And it works for both older and newer versions of GCC/Clang in the same way. The benefits of the -g1 option are indeed questionable except that it produces an image with ~20% less in size. > It seems like a great way to bloat > vmlinux artifacts built with CONFIG_DEBUG_INFO even further. The defaults were chosen to not change the build behavior that was before introducing the options. Or did you mean something else? > The > above link mentions "when debugging with GDB." In that case, please > don't add new Kconfigs for these; just set -g3 when > CONFIG_GDB_SCRIPTS=y. CONFIG_GDB_SCRIPTS does not necessarily mean that -g3 is wanted, -g2 (default) is usually a reasonable choice. The -g3 option is very useful when debugging macro-intensive code, but requires much more disk space to build. I documented it explicitly in the help section of DEBUG_INFO_LEVEL. GCC and Clang use different options to include macro definitions so it was handled depending on the compiler used. Regards Dmitrii
On Fri, Aug 19, 2022 at 3:52 PM Dmitrii Bundin <dmitrii.bundin.a@gmail.com> wrote: > > On Fri, Aug 19, 2022 at 8:42 PM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > Is any of this really necessary? > > Consider the case if CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y. > Prior to GCC11/Clang12 -gsplit-dwarf implied -g2. So on newer > compilers with -gsplit-dwarf in use there would be no debug symbols > produced. ``` diff --git a/scripts/Makefile.debug b/scripts/Makefile.debug index 9f39b0130551..a881954c1382 100644 --- a/scripts/Makefile.debug +++ b/scripts/Makefile.debug @@ -1,7 +1,7 @@ DEBUG_CFLAGS := ifdef CONFIG_DEBUG_INFO_SPLIT -DEBUG_CFLAGS += -gsplit-dwarf +DEBUG_CFLAGS += -gsplit-dwarf -g2 else DEBUG_CFLAGS += -g endif ``` or perhaps that simply needs to be `-g -gsplit-dwarf`? In which case, that if/else could just be re-arranged. > -gdwarf-4/5 still implies -g2, but in case > CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y neither of the options are > set. -g is set, which has an implicit default level. > So it seems like a reasonable choice to provide a debug info > level config that would explicitly set the level without relying on > implicits. The default value of the config is set to -g2 to not change > the build behavior that was before introducing the option. And it > works for both older and newer versions of GCC/Clang in the same way. > The benefits of the -g1 option are indeed questionable except that it > produces an image with ~20% less in size. Until there's a concrete need, YAGNI. > > > It seems like a great way to bloat > > vmlinux artifacts built with CONFIG_DEBUG_INFO even further. > The defaults were chosen to not change the build behavior that was > before introducing the options. Or did you mean something else? > > > The > > above link mentions "when debugging with GDB." In that case, please > > don't add new Kconfigs for these; just set -g3 when > > CONFIG_GDB_SCRIPTS=y. > > CONFIG_GDB_SCRIPTS does not necessarily mean that -g3 is wanted, -g2 > (default) is usually a reasonable choice. The -g3 option is very > useful when debugging macro-intensive code, but requires much more > disk space to build. I documented it explicitly in the help section of > DEBUG_INFO_LEVEL. GCC and Clang use different options to include macro > definitions so it was handled depending on the compiler used. Honestly, I really don't think we need to be wrapping every compiler command line flag under the sun in a kconfig option.
On Mon, Aug 22, 2022 at 9:45 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > > So it seems like a reasonable choice to provide a debug info > > level config that would explicitly set the level without relying on > > implicits. The default value of the config is set to -g2 to not change > > the build behavior that was before introducing the option. And it > > works for both older and newer versions of GCC/Clang in the same way. > > The benefits of the -g1 option are indeed questionable except that it > > produces an image with ~20% less in size. > > Until there's a concrete need, YAGNI. Or add -g1 to CONFIG_DEBUG_INFO_REDUCED.
On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > or perhaps that simply needs to be `-g -gsplit-dwarf`? In which case, > that if/else could just be re-arranged. How about simply assigning DEBUG_CFLAGS := -g at the very beginning without any conditions? This would provide the default with the possibility of overriding later and -gsplit-dwarf does not necessarily come with -g implicitly. > Honestly, I really don't think we need to be wrapping every compiler > command line flag under the sun in a kconfig option. This indeed sounds reasonable to me. So the key point here is to not bloat the kconfig with options related to every compiler flag. But I think it still might be useful to provide some option that would include sort of full debug information compilers may produce. With this approach there would be, in fact 3 different levels of debug information supported by Kconfig: reduced, default and full. The full level would increase everything like -g3, and -fdebug-macro for Clang, and probably others. > Or add -g1 to CONFIG_DEBUG_INFO_REDUCED. I ran some tests and there was indeed some decrease in size. That combination probably might be useful. Any thoughts? Regards Dmitrii
On Sat, Aug 20, 2022 at 01:52:04AM +0300, Dmitrii Bundin wrote: > On Fri, Aug 19, 2022 at 8:42 PM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > Is any of this really necessary? > > Consider the case if CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y. Can I just say I *HATE* that thing? It uesd to be I could do: ../scripts/config --enable DEBUG_INFO and I'd get a debug-info build, now I gotta use that horrible piece of crap you just mentioned which I mis-type at least once every single time.
On Mon, Aug 22, 2022 at 3:42 PM Dmitrii Bundin <dmitrii.bundin.a@gmail.com> wrote: > > On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > or perhaps that simply needs to be `-g -gsplit-dwarf`? In which case, > > that if/else could just be re-arranged. > > How about simply assigning DEBUG_CFLAGS := -g at the very beginning > without any conditions? This would provide the default with the > possibility of overriding later and -gsplit-dwarf does not necessarily > come with -g implicitly. SGTM; I'd accept such a patch. > > Honestly, I really don't think we need to be wrapping every compiler > > command line flag under the sun in a kconfig option. > > This indeed sounds reasonable to me. So the key point here is to not > bloat the kconfig with options related to every compiler flag. But I > think it still might be useful to provide some option that would > include sort of full debug information compilers may produce. With > this approach there would be, in fact 3 different levels of debug > information supported by Kconfig: reduced, default and full. The full > level would increase everything like -g3, and -fdebug-macro for Clang, > and probably others. Has anyone asked for that though? It seems like your intent with this patch is to fix the surprising+user hostile behavior of compilers requiring -g to be used when -gsplit-dwarf is used. If someone using GDB_SCRIPTS or KGDB was like "man, I wish I could debug macros" then sure I'd be more likely to accept this. Without the need, this is just wrapping every compiler option in a kconfig, which frustrates randconfig testing bots. This will slow them down and bloat their artifacts when randconfig selects -g3, so I'd like someone to come forward saying they need this and why. > > > Or add -g1 to CONFIG_DEBUG_INFO_REDUCED. > > I ran some tests and there was indeed some decrease in size. That > combination probably might be useful. > > Any thoughts? I think there's also -gmlt; when that is preferable to -g1 IDK. Why either of those weren't used in the first place, IDK. The help text in DEBUG_INFO_REDUCED in lib/Kconfig.debug makes it sound like -gmlt is what is wanted. Maybe that should be updated. But I think DEBUG_INFO_REDUCED is redundant if we were to accept DEBUG_INFO_LEVEL. Both don't need to exist IMO.
On Tue, Aug 23, 2022 at 7:42 AM Dmitrii Bundin <dmitrii.bundin.a@gmail.com> wrote: > > On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > or perhaps that simply needs to be `-g -gsplit-dwarf`? In which case, > > that if/else could just be re-arranged. > > How about simply assigning DEBUG_CFLAGS := -g at the very beginning > without any conditions? This would provide the default with the > possibility of overriding later and -gsplit-dwarf does not necessarily > come with -g implicitly. This was fixed by commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe, which is now in the mainline. > > Honestly, I really don't think we need to be wrapping every compiler > > command line flag under the sun in a kconfig option. > > This indeed sounds reasonable to me. So the key point here is to not > bloat the kconfig with options related to every compiler flag. But I > think it still might be useful to provide some option that would > include sort of full debug information compilers may produce. With > this approach there would be, in fact 3 different levels of debug > information supported by Kconfig: reduced, default and full. The full > level would increase everything like -g3, and -fdebug-macro for Clang, > and probably others. I think that would be much saner than this patch. CONFIG_DEBUG_INFO_LEVEL is a direct way to specify the debug level. CONFIG_DEBUG_MACRO_DEFINITIONS is feature-driven. Do not mix two different ways. CONFIG_DEBUG_INFO_LEVEL is here just because Andrew Morton suggested that. The debug level is compiler-specific. There is no guarantee that there is a common range. The debug level range of GCC is 0-3. Clang accepts 3, but -g3 has no effect. The debug level range of Rustc is 0-2. See how badly scripts/Makefile.debug looks in linux-next. How should Rustc behave for CONFIG_DEBUG_INFO_LEVEL=3 ? -Cdebuginfo=3 is a compile error. RUSTC L rust/core.o error: debug info level needs to be between 0-2 (instead was `3`) You cannot directly specify the debug level number given that we support multiple compilers with different policy for debug level options. > > Or add -g1 to CONFIG_DEBUG_INFO_REDUCED. > > I ran some tests and there was indeed some decrease in size. That > combination probably might be useful. > > Any thoughts? > > Regards > Dmitrii
On Fri, Sep 30, 2022 at 6:06 AM Masahiro Yamada <masahiroy@kernel.org> wrote: > > On Tue, Aug 23, 2022 at 7:42 AM Dmitrii Bundin > <dmitrii.bundin.a@gmail.com> wrote: > > > > On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers > > <ndesaulniers@google.com> wrote: > > > > > > or perhaps that simply needs to be `-g -gsplit-dwarf`? In which case, > > > that if/else could just be re-arranged. > > > > How about simply assigning DEBUG_CFLAGS := -g at the very beginning > > without any conditions? This would provide the default with the > > possibility of overriding later and -gsplit-dwarf does not necessarily > > come with -g implicitly. > > This was fixed by commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe, > which is now in the mainline. > > > > > > > Honestly, I really don't think we need to be wrapping every compiler > > > command line flag under the sun in a kconfig option. > > > > This indeed sounds reasonable to me. So the key point here is to not > > bloat the kconfig with options related to every compiler flag. But I > > think it still might be useful to provide some option that would > > include sort of full debug information compilers may produce. With > > this approach there would be, in fact 3 different levels of debug > > information supported by Kconfig: reduced, default and full. The full > > level would increase everything like -g3, and -fdebug-macro for Clang, > > and probably others. > > > I think that would be much saner than this patch. > > > > CONFIG_DEBUG_INFO_LEVEL is a direct way to specify the debug level. > > CONFIG_DEBUG_MACRO_DEFINITIONS is feature-driven. > > Do not mix two different ways. > > > > > > > CONFIG_DEBUG_INFO_LEVEL is here just because Andrew Morton suggested that. > > > The debug level is compiler-specific. There is no guarantee > that there is a common range. > > > The debug level range of GCC is 0-3. > Clang accepts 3, but -g3 has no effect. > The debug level range of Rustc is 0-2. > > See how badly scripts/Makefile.debug looks in linux-next. > > > > > > How should Rustc behave for CONFIG_DEBUG_INFO_LEVEL=3 ? > > -Cdebuginfo=3 is a compile error. > > RUSTC L rust/core.o > error: debug info level needs to be between 0-2 (instead was `3`) > > > > You cannot directly specify the debug level number given that > we support multiple compilers with different policy for > debug level options. > > > > > > > > > Or add -g1 to CONFIG_DEBUG_INFO_REDUCED. > > > > I ran some tests and there was indeed some decrease in size. That > > combination probably might be useful. > > > > Any thoughts? > > > > Regards > > Dmitrii > > > > > > -- > Best Regards > Masahiro Yamada I proposed to do a ground-work like the following first. https://patchwork.kernel.org/project/linux-kbuild/patch/20220930085351.2648034-1-masahiroy@kernel.org/ On top of that, it is easier to add CONFIG_DEBUG_INFO_FULL or whatever. And, -g1 for CONFIG_DEBUG_INFO_REDUCED if you think it is worthwhile.
Hi Masahiro, > On top of that, it is easier to add CONFIG_DEBUG_INFO_FULL or whatever. As per the prior discussion, Nick has convinced me that configuring an additional choice for a full debug info might cause more problems that it solves in general. >And, -g1 for CONFIG_DEBUG_INFO_REDUCED if you think it is worthwhile. This indeed would shrink the image size, but with this option enabled there would be no information about local variables which might surprise users of the option. So I don't really think it is worthwhile. Regards, Dmitrii.
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 2e24db4bff19..ace6f2eddb56 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -304,6 +304,26 @@ config DEBUG_INFO_REDUCED DEBUG_INFO build and compile times are reduced too. Only works with newer gcc versions. +config DEBUG_INFO_LEVEL + int "Debug info level" + range 1 3 + default "2" + help + Sets the level of how much debug information to generate (-glevel). + Level 1 produces minimal debug information without including information + about local variables. Level 3 includes extra information like macro + definitions. Setting up level 3 will require significantly more disk + space and increase built time. + +config DEBUG_MACRO_DEFINITIONS + bool "Add macro definitions to debug info" + default n + help + Generates macro definitions to provide a way to expand macros right + in the debugging session. This information can be used with macro expand, + info macro in gdb. This option is equivalent to setting -g3 in GCC and + -fdebug-macro in Clang. + config DEBUG_INFO_COMPRESSED bool "Compressed debugging information" depends on $(cc-option,-gz=zlib) diff --git a/scripts/Makefile.debug b/scripts/Makefile.debug index 9f39b0130551..29cd04234e75 100644 --- a/scripts/Makefile.debug +++ b/scripts/Makefile.debug @@ -2,8 +2,6 @@ DEBUG_CFLAGS := ifdef CONFIG_DEBUG_INFO_SPLIT DEBUG_CFLAGS += -gsplit-dwarf -else -DEBUG_CFLAGS += -g endif ifndef CONFIG_AS_IS_LLVM @@ -16,6 +14,16 @@ dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5 DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) endif +DEBUG_CFLAGS += -g$(CONFIG_DEBUG_INFO_LEVEL) +ifdef CONFIG_DEBUG_MACRO_DEFINITIONS +ifdef CONFIG_CC_IS_GCC +DEBUG_CFLAGS += -g3 +endif +ifdef CONFIG_CC_IS_CLANG +DEBUG_CFLAGS += -fdebug-macro +endif +endif + ifdef CONFIG_DEBUG_INFO_REDUCED DEBUG_CFLAGS += -fno-var-tracking ifdef CONFIG_CC_IS_GCC
Adds config options to control debug info level and producing of macro definitions for GCC/Clang. Option DEBUG_INFO_LEVEL is responsible for controlling debug info level. Before GCC 11 and Clang 12 -gsplit-dwarf implicitly uses -g2. To provide a way to override the setting with, e.g. -g1, DEBUG_INFO_LEVEL is set independently from DEBUG_INFO_SPLIT. Option DEBUG_MACRO_DEFINITIONS is responsible for controlling inclusion of macro definitions. Since Clang uses -fdebug-macro to control if macro definitions are produced which is different from GCC, provides a compiler-specific way of handling macro inclusion. The option is handled after DEBUG_INFO_LEVEL since -g3 -g2 implies -g2, but -g2 -g3 implies -g3 and GCC uses -g3 to produce macro definitions. Signed-off-by: Dmitrii Bundin <dmitrii.bundin.a@gmail.com> --- Changes in v2: https://lore.kernel.org/all/20220804223504.4739-1-dmitrii.bundin.a@gmail.com/ - Replace hardcoded -g3 with a configurable debug info level Changes in v3: https://lore.kernel.org/all/20220814002021.16990-1-dmitrii.bundin.a@gmail.com/ - Make -g<level> and -gdwarf-split to be set independently - Add a separate option to control macro definitions for GCC/Clang lib/Kconfig.debug | 20 ++++++++++++++++++++ scripts/Makefile.debug | 12 ++++++++++-- 2 files changed, 30 insertions(+), 2 deletions(-)