Provides a way to configure debug info level (-glevel).
Debug level 3 includes extra information such as macro definitions. With
level 3 enabled it's possible to expand macros right from the debugging
session in gdb simplifying debugging when complicated macros involved.
The default level is set to 2 to not change the default build behavior.
Signed-off-by: Dmitrii Bundin <[email protected]>
---
Changes in v2: https://lore.kernel.org/all/[email protected]/
- Replace hardcoded -g3 with a configurable debug info level
lib/Kconfig.debug | 11 +++++++++++
scripts/Makefile.debug | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2e24db4bff19..a17c12c20290 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -304,6 +304,17 @@ 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 0 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. Level 0 produces no debug information.
+
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..28beffc42e71 100644
--- a/scripts/Makefile.debug
+++ b/scripts/Makefile.debug
@@ -3,7 +3,7 @@ DEBUG_CFLAGS :=
ifdef CONFIG_DEBUG_INFO_SPLIT
DEBUG_CFLAGS += -gsplit-dwarf
else
-DEBUG_CFLAGS += -g
+DEBUG_CFLAGS += -g$(CONFIG_DEBUG_INFO_LEVEL)
endif
ifndef CONFIG_AS_IS_LLVM
--
2.17.1
+CC: Fangrui Song <[email protected]>
On Sun, Aug 14, 2022 at 9:25 AM Dmitrii Bundin
<[email protected]> wrote:
>
> Provides a way to configure debug info level (-glevel).
> Debug level 3 includes extra information such as macro definitions. With
> level 3 enabled it's possible to expand macros right from the debugging
> session in gdb simplifying debugging when complicated macros involved.
> The default level is set to 2 to not change the default build behavior.
>
> Signed-off-by: Dmitrii Bundin <[email protected]>
> ---
>
> Changes in v2: https://lore.kernel.org/all/[email protected]/
> - Replace hardcoded -g3 with a configurable debug info level
>
> lib/Kconfig.debug | 11 +++++++++++
> scripts/Makefile.debug | 2 +-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 2e24db4bff19..a17c12c20290 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -304,6 +304,17 @@ 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 0 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. Level 0 produces no debug information.
> +
We already have CONFIG_DEBUG_INFO_NONE to
disable the debug info.
The combination of CONFIG_DEBUG_INFO=y and
CONFIG_DEBUG_INFO_LEVEL=0 (-g0)
would emulate CONFIG_DEBUG_INFO_NONE ?
Using 'int' does not look sensible to me.
> 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..28beffc42e71 100644
> --- a/scripts/Makefile.debug
> +++ b/scripts/Makefile.debug
> @@ -3,7 +3,7 @@ DEBUG_CFLAGS :=
> ifdef CONFIG_DEBUG_INFO_SPLIT
> DEBUG_CFLAGS += -gsplit-dwarf
> else
> -DEBUG_CFLAGS += -g
> +DEBUG_CFLAGS += -g$(CONFIG_DEBUG_INFO_LEVEL)
> endif
>
> ifndef CONFIG_AS_IS_LLVM
> --
> 2.17.1
>
I want to consult Fangrui Song for this part.
With this Makefile code, CONFIG_DEBUG_INFO_SPLIT
takes the presidency over CONFIG_DEBUG_INFO_LEVEL.
When CONFIG_DEBUG_INFO_SPLIT is enabled (-gsplit-dwarf),
it always uses the default -g2 level.
CONFIG_DEBUG_INFO_LEVEL is just ignored silently.
It might be sensible in older GCC/Clang behavior because
-gsplit-dwarf implied -g2.
But, with this commit:
https://reviews.llvm.org/D80391
-gsplit-dwarf and -g<level> are orthogonal
for GCC 11+/Clang 12+, correct?
I think "splitting debug files" and "debug level"
should be controlled independently.
(but it depends on the compiler version, if I understood correctly)
--
Best Regards
Masahiro Yamada
On 2022-08-14, Masahiro Yamada wrote:
>+CC: Fangrui Song <[email protected]>
>
>
>
>
>On Sun, Aug 14, 2022 at 9:25 AM Dmitrii Bundin
><[email protected]> wrote:
>>
>> Provides a way to configure debug info level (-glevel).
>> Debug level 3 includes extra information such as macro definitions. With
>> level 3 enabled it's possible to expand macros right from the debugging
>> session in gdb simplifying debugging when complicated macros involved.
>> The default level is set to 2 to not change the default build behavior.
GCC -g3 generates macro information (in the .debug_macro section).
In Clang, -g = -g2 = -g3. To generate macro information,
specify -fdebug-macro.
The different choice is known in the initial implementation https://reviews.llvm.org/D16135 .
Not generating macro information for -g3 (i.e. diverging from GCC
behavior) makes some sense to me: -fstandalone-debug will probably be
more suitable as -g3 (it retains some type debug info for C++ (the code
after https://github.com/llvm/llvm-project/blob/b2f31cac28c8a03ceb908b544f5790f4f9f2d9ab/clang/lib/CodeGen/CGDebugInfo.cpp#L2497-L2499).
>> Signed-off-by: Dmitrii Bundin <[email protected]>
>> ---
>>
>> Changes in v2: https://lore.kernel.org/all/[email protected]/
>> - Replace hardcoded -g3 with a configurable debug info level
>>
>> lib/Kconfig.debug | 11 +++++++++++
>> scripts/Makefile.debug | 2 +-
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>> index 2e24db4bff19..a17c12c20290 100644
>> --- a/lib/Kconfig.debug
>> +++ b/lib/Kconfig.debug
>> @@ -304,6 +304,17 @@ 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 0 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. Level 0 produces no debug information.
>> +
>
>
>
>We already have CONFIG_DEBUG_INFO_NONE to
>disable the debug info.
>
>
>The combination of CONFIG_DEBUG_INFO=y and
>CONFIG_DEBUG_INFO_LEVEL=0 (-g0)
>would emulate CONFIG_DEBUG_INFO_NONE ?
>
>
>
>Using 'int' does not look sensible to me.
>
>
>
>
>
>> 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..28beffc42e71 100644
>> --- a/scripts/Makefile.debug
>> +++ b/scripts/Makefile.debug
>> @@ -3,7 +3,7 @@ DEBUG_CFLAGS :=
>> ifdef CONFIG_DEBUG_INFO_SPLIT
>> DEBUG_CFLAGS += -gsplit-dwarf
>> else
>> -DEBUG_CFLAGS += -g
>> +DEBUG_CFLAGS += -g$(CONFIG_DEBUG_INFO_LEVEL)
>> endif
>>
>> ifndef CONFIG_AS_IS_LLVM
>> --
>> 2.17.1
>>
>
>
>I want to consult Fangrui Song for this part.
>
>
>With this Makefile code, CONFIG_DEBUG_INFO_SPLIT
>takes the presidency over CONFIG_DEBUG_INFO_LEVEL.
>
>
>When CONFIG_DEBUG_INFO_SPLIT is enabled (-gsplit-dwarf),
>it always uses the default -g2 level.
>CONFIG_DEBUG_INFO_LEVEL is just ignored silently.
>
>
>
>It might be sensible in older GCC/Clang behavior because
>-gsplit-dwarf implied -g2.
>
>
>But, with this commit:
>https://reviews.llvm.org/D80391
>
>-gsplit-dwarf and -g<level> are orthogonal
>for GCC 11+/Clang 12+, correct?
Correct.
>I think "splitting debug files" and "debug level"
>should be controlled independently.
>(but it depends on the compiler version, if I understood correctly)
Before GCC 11 and Clang 12, -gsplit-dwarf implied -g2 (older
-gsplit-dwarf is like today's `-gsplit-dwarf -g2`).
GCC 11 and Clang 12 (https://reviews.llvm.org/D80391) have changed
-gsplit-dwarf to not imply -g2.
For a group of -g0 -g1 -g2, the last option wins. Therefore,
-g0 -gsplit-dwarf => debug info in GCC<11 and Clang<12
-g0 -gsplit-dwarf => no debug info in GCC>=11 and Clang>=12
On Sun, Aug 14, 2022 at 2:31 PM Fangrui Song <[email protected]> wrote:
>
> On 2022-08-14, Masahiro Yamada wrote:
> >+CC: Fangrui Song <[email protected]>
> >
> >
> >
> >
> >On Sun, Aug 14, 2022 at 9:25 AM Dmitrii Bundin
> ><[email protected]> wrote:
> >>
> >> Provides a way to configure debug info level (-glevel).
> >> Debug level 3 includes extra information such as macro definitions. With
> >> level 3 enabled it's possible to expand macros right from the debugging
> >> session in gdb simplifying debugging when complicated macros involved.
> >> The default level is set to 2 to not change the default build behavior.
>
> GCC -g3 generates macro information (in the .debug_macro section).
>
> In Clang, -g = -g2 = -g3. To generate macro information,
> specify -fdebug-macro.
> The different choice is known in the initial implementation https://reviews.llvm.org/D16135 .
>
> Not generating macro information for -g3 (i.e. diverging from GCC
> behavior) makes some sense to me: -fstandalone-debug will probably be
> more suitable as -g3 (it retains some type debug info for C++ (the code
> after https://github.com/llvm/llvm-project/blob/b2f31cac28c8a03ceb908b544f5790f4f9f2d9ab/clang/lib/CodeGen/CGDebugInfo.cpp#L2497-L2499).
>
> >> Signed-off-by: Dmitrii Bundin <[email protected]>
> >> ---
> >>
> >> Changes in v2: https://lore.kernel.org/all/[email protected]/
> >> - Replace hardcoded -g3 with a configurable debug info level
> >>
> >> lib/Kconfig.debug | 11 +++++++++++
> >> scripts/Makefile.debug | 2 +-
> >> 2 files changed, 12 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> >> index 2e24db4bff19..a17c12c20290 100644
> >> --- a/lib/Kconfig.debug
> >> +++ b/lib/Kconfig.debug
> >> @@ -304,6 +304,17 @@ 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 0 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. Level 0 produces no debug information.
> >> +
> >
> >
> >
> >We already have CONFIG_DEBUG_INFO_NONE to
> >disable the debug info.
> >
> >
> >The combination of CONFIG_DEBUG_INFO=y and
> >CONFIG_DEBUG_INFO_LEVEL=0 (-g0)
> >would emulate CONFIG_DEBUG_INFO_NONE ?
> >
> >
> >
> >Using 'int' does not look sensible to me.
> >
> >
> >
> >
> >
> >> 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..28beffc42e71 100644
> >> --- a/scripts/Makefile.debug
> >> +++ b/scripts/Makefile.debug
> >> @@ -3,7 +3,7 @@ DEBUG_CFLAGS :=
> >> ifdef CONFIG_DEBUG_INFO_SPLIT
> >> DEBUG_CFLAGS += -gsplit-dwarf
> >> else
> >> -DEBUG_CFLAGS += -g
> >> +DEBUG_CFLAGS += -g$(CONFIG_DEBUG_INFO_LEVEL)
> >> endif
> >>
> >> ifndef CONFIG_AS_IS_LLVM
> >> --
> >> 2.17.1
> >>
> >
> >
> >I want to consult Fangrui Song for this part.
> >
> >
> >With this Makefile code, CONFIG_DEBUG_INFO_SPLIT
> >takes the presidency over CONFIG_DEBUG_INFO_LEVEL.
> >
> >
> >When CONFIG_DEBUG_INFO_SPLIT is enabled (-gsplit-dwarf),
> >it always uses the default -g2 level.
> >CONFIG_DEBUG_INFO_LEVEL is just ignored silently.
> >
> >
> >
> >It might be sensible in older GCC/Clang behavior because
> >-gsplit-dwarf implied -g2.
> >
> >
> >But, with this commit:
> >https://reviews.llvm.org/D80391
> >
> >-gsplit-dwarf and -g<level> are orthogonal
> >for GCC 11+/Clang 12+, correct?
>
> Correct.
>
> >I think "splitting debug files" and "debug level"
> >should be controlled independently.
> >(but it depends on the compiler version, if I understood correctly)
>
> Before GCC 11 and Clang 12, -gsplit-dwarf implied -g2 (older
> -gsplit-dwarf is like today's `-gsplit-dwarf -g2`).
>
> GCC 11 and Clang 12 (https://reviews.llvm.org/D80391) have changed
> -gsplit-dwarf to not imply -g2.
>
> For a group of -g0 -g1 -g2, the last option wins. Therefore,
>
> -g0 -gsplit-dwarf => debug info in GCC<11 and Clang<12
> -g0 -gsplit-dwarf => no debug info in GCC>=11 and Clang>=12
Thanks.
I tested GCC 9 on Ubuntu 22.04.
"-g3 -gsplit-dwarf" produces .debug_macro
In old behavior, -gsplit-dwarf upgrades the level, but
does not downgrade it, correct?
[Old behavior]
-g0 -gsplit-dwarf --> level 2 (gsplit-dwarf upgrade 0 to 2)
-gsplit-dwarf -g0 --> level 0 (the last -g0 wins)
-g3 -gsplit-dwarf --> level 3 (gsplit-dwarf does not downgrade)
-g2 -g3 --> level 3 (the last -g3 wins)
-g3 -g2 --> level 2 (the last -g2 wins)
[New behavior]
-g0 -gsplit-dwarf --> level 0 (the options are orthogonal)
-gsplit-dwarf -g0 --> level 0 (the options are orthogonal)
-g3 -gsplit-dwarf --> level 3 (the options are orthogonal)
-g2 -g3 --> level 3 (the last -g3 wins)
-g3 -g2 --> level 2 (the last -g2 wins)
masahiro@grover:/tmp/foo$ gcc-9 --version
gcc-9 (Ubuntu 9.4.0-5ubuntu1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
masahiro@grover:/tmp/foo$ rm -f *.dwo
masahiro@grover:/tmp/foo$ gcc-9 -gsplit-dwarf -o foo foo.c
masahiro@grover:/tmp/foo$ readelf -S foo.dwo
There are 9 section headers, starting at offset 0x840:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .debug_info.dwo PROGBITS 0000000000000000 00000040
0000000000000217 0000000000000000 E 0 0 1
[ 2] .debug_abbrev.dwo PROGBITS 0000000000000000 00000257
00000000000000cb 0000000000000000 E 0 0 1
[ 3] .debug_line.dwo PROGBITS 0000000000000000 00000322
00000000000000e5 0000000000000000 E 0 0 1
[ 4] .debug_str_o[...] PROGBITS 0000000000000000 00000407
00000000000000d4 0000000000000000 E 0 0 1
[ 5] .debug_str.dwo PROGBITS 0000000000000000 000004db
00000000000002bd 0000000000000000 E 0 0 1
[ 6] .symtab SYMTAB 0000000000000000 00000798
0000000000000030 0000000000000018 7 2 8
[ 7] .strtab STRTAB 0000000000000000 000007c8
0000000000000001 0000000000000000 0 0 1
[ 8] .shstrtab STRTAB 0000000000000000 000007c9
0000000000000073 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
masahiro@grover:/tmp/foo$ rm -f *.dwo
masahiro@grover:/tmp/foo$ gcc-9 -g3 -gsplit-dwarf -o foo foo.c
masahiro@grover:/tmp/foo$ readelf -S foo.dwo
There are 32 section headers, starting at offset 0x77f8:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .debug_info.dwo PROGBITS 0000000000000000 00000040
0000000000000245 0000000000000000 E 0 0 1
[ 2] .debug_abbrev.dwo PROGBITS 0000000000000000 00000285
00000000000000ce 0000000000000000 E 0 0 1
[ 3] .debug_macro.dwo PROGBITS 0000000000000000 00000353
000000000000014a 0000000000000000 E 0 0 1
[ 4] .debug_macro.dwo PROGBITS 0000000000000000 0000049d
0000000000000528 0000000000000000 0 0 1
[ 5] .debug_macro.dwo PROGBITS 0000000000000000 000009c5
000000000000001c 0000000000000000 0 0 1
[ 6] .debug_macro.dwo PROGBITS 0000000000000000 000009e1
000000000000000c 0000000000000000 0 0 1
[ 7] .debug_macro.dwo PROGBITS 0000000000000000 000009ed
000000000000010b 0000000000000000 0 0 1
[ 8] .debug_macro.dwo PROGBITS 0000000000000000 00000af8
0000000000000010 0000000000000000 0 0 1
[ 9] .debug_macro.dwo PROGBITS 0000000000000000 00000b08
0000000000000033 0000000000000000 0 0 1
[10] .debug_macro.dwo PROGBITS 0000000000000000 00000b3b
0000000000000143 0000000000000000 0 0 1
[11] .debug_macro.dwo PROGBITS 0000000000000000 00000c7e
0000000000000056 0000000000000000 0 0 1
[12] .debug_macro.dwo PROGBITS 0000000000000000 00000cd4
0000000000000021 0000000000000000 0 0 1
[13] .debug_macro.dwo PROGBITS 0000000000000000 00000cf5
0000000000000037 0000000000000000 0 0 1
[14] .debug_macro.dwo PROGBITS 0000000000000000 00000d2c
000000000000000b 0000000000000000 0 0 1
[15] .debug_macro.dwo PROGBITS 0000000000000000 00000d37
0000000000000068 0000000000000000 0 0 1
[16] .debug_macro.dwo PROGBITS 0000000000000000 00000d9f
000000000000000c 0000000000000000 0 0 1
[17] .debug_macro.dwo PROGBITS 0000000000000000 00000dab
0000000000000048 0000000000000000 0 0 1
[18] .debug_macro.dwo PROGBITS 0000000000000000 00000df3
00000000000000a8 0000000000000000 0 0 1
[19] .debug_macro.dwo PROGBITS 0000000000000000 00000e9b
000000000000000b 0000000000000000 0 0 1
[20] .debug_macro.dwo PROGBITS 0000000000000000 00000ea6
0000000000000023 0000000000000000 0 0 1
[21] .debug_macro.dwo PROGBITS 0000000000000000 00000ec9
0000000000000030 0000000000000000 0 0 1
[22] .debug_macro.dwo PROGBITS 0000000000000000 00000ef9
0000000000000020 0000000000000000 0 0 1
[23] .debug_macro.dwo PROGBITS 0000000000000000 00000f19
000000000000001d 0000000000000000 0 0 1
[24] .debug_macro.dwo PROGBITS 0000000000000000 00000f36
0000000000000020 0000000000000000 0 0 1
[25] .debug_macro.dwo PROGBITS 0000000000000000 00000f56
0000000000000059 0000000000000000 0 0 1
[26] .debug_line.dwo PROGBITS 0000000000000000 00000faf
0000000000000255 0000000000000000 E 0 0 1
[27] .debug_str_o[...] PROGBITS 0000000000000000 00001204
0000000000000bd4 0000000000000000 E 0 0 1
[28] .debug_str.dwo PROGBITS 0000000000000000 00001dd8
0000000000005721 0000000000000000 E 0 0 1
[29] .symtab SYMTAB 0000000000000000 00007500
0000000000000270 0000000000000018 30 26 8
[30] .strtab STRTAB 0000000000000000 00007770
0000000000000001 0000000000000000 0 0 1
[31] .shstrtab STRTAB 0000000000000000 00007771
0000000000000084 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
D (mbind), l (large), p (processor specific)
--
Best Regards
Masahiro Yamada
> We already have CONFIG_DEBUG_INFO_NONE to
> disable the debug info.
Thanks for pointing this out. Indeed providing another way of
disabling debug info does not look reasonable to me.
So only it makes sense to set only 1, 2 or 3 debug levels.
> Using 'int' does not look sensible to me.
Could you please give a hint why?
My intention to choose int was to provide a boundary with range on the
DEBUG_INFO_LEVEL option to choose only acceptable ones.
On Sun, Aug 14, 2022 at 8:31 AM Fangrui Song <[email protected]> wrote:
> In Clang, -g = -g2 = -g3. To generate macro information,
> specify -fdebug-macro.
Thanks.
I would propose to add another config option like
DEBUG_MACRO_DEFINITIONS to turn on macro information for GCC/Clang.
For GCC it would be -g3, for Clang -fdebug-macro.
> Before GCC 11 and Clang 12, -gsplit-dwarf implied -g2 (older
> -gsplit-dwarf is like today's `-gsplit-dwarf -g2`).
>
> GCC 11 and Clang 12 (https://reviews.llvm.org/D80391) have changed
> -gsplit-dwarf to not imply -g2.
>
> For a group of -g0 -g1 -g2, the last option wins. Therefore,
>
> -g0 -gsplit-dwarf => debug info in GCC<11 and Clang<12
> -g0 -gsplit-dwarf => no debug info in GCC>=11 and Clang>=12
I would add a note that when selecting -gdwarf-<level> gcc also
implicitly sets -g2 (at least in older versions).
It seems reasonable to me to put the DEBUG_LEVEL_INFO setting at the
very bottom to prevent it from overriding implicitly.
What do you think?
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 <[email protected]>
---
Changes in v2: https://lore.kernel.org/all/[email protected]/
- Replace hardcoded -g3 with a configurable debug info level
Changes in v3: https://lore.kernel.org/all/[email protected]/
- 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
On Mon, Aug 15, 2022 at 10:34 AM Dmitrii Bundin
<[email protected]> 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 <[email protected]>
> ---
>
> Changes in v2: https://lore.kernel.org/all/[email protected]/
> - Replace hardcoded -g3 with a configurable debug info level
>
> Changes in v3: https://lore.kernel.org/all/[email protected]/
> - 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 <[email protected]> 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
<[email protected]> 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 <[email protected]>
> ---
>
> Changes in v2: https://lore.kernel.org/all/[email protected]/
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.
--
Thanks,
~Nick Desaulniers
On Fri, Aug 19, 2022 at 8:42 PM Nick Desaulniers
<[email protected]> 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
<[email protected]> wrote:
>
> On Fri, Aug 19, 2022 at 8:42 PM Nick Desaulniers
> <[email protected]> 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.
--
Thanks,
~Nick Desaulniers
On Mon, Aug 22, 2022 at 9:45 AM Nick Desaulniers
<[email protected]> 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.
--
Thanks,
~Nick Desaulniers
On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers
<[email protected]> 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
> <[email protected]> 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
<[email protected]> wrote:
>
> On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers
> <[email protected]> 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.
--
Thanks,
~Nick Desaulniers
On Tue, Aug 23, 2022 at 7:42 AM Dmitrii Bundin
<[email protected]> wrote:
>
> On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers
> <[email protected]> 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
On Fri, Sep 30, 2022 at 6:06 AM Masahiro Yamada <[email protected]> wrote:
>
> On Tue, Aug 23, 2022 at 7:42 AM Dmitrii Bundin
> <[email protected]> wrote:
> >
> > On Tue, Aug 23, 2022 at 12:36 AM Nick Desaulniers
> > <[email protected]> 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/[email protected]/
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.
--
Best Regards
Masahiro Yamada
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.