From: Nathan Chancellor <nathan@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Nick Desaulniers <ndesaulniers@google.com>,
Miguel Ojeda <ojeda@kernel.org>
Subject: Re: [PATCH 3/3] Kconfig.debug: split debug-level and DWARF-version into separate choices
Date: Mon, 3 Oct 2022 10:20:14 -0700 [thread overview]
Message-ID: <YzsZzjjJFcPILOji@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20221002181107.51286-4-masahiroy@kernel.org>
On Mon, Oct 03, 2022 at 03:11:07AM +0900, Masahiro Yamada wrote:
> Commit f9b3cd245784 ("Kconfig.debug: make DEBUG_INFO selectable from
> a choice") added CONFIG_DEBUG_INFO_NONE into the DWARF version choice,
> but it should rather belong to the debug level choice.
>
> This commit consolidates CONFIG options into two choices:
>
> - Debug info level (NONE / REDUCED / DEFAULT)
>
> - DWARF format (DWARF_TOOLCHAIN_DEFAULT / DWARF4 / DWARF5)
>
> This is more consistent with compilers' policy because the -g0 compiler
> flag means "no debug info".
>
> GCC manual:
>
> -g<level>
>
> Request debugging information and also use level to specify how
> much information. The default level is 2.
>
> Level 0 produces no debug information at all. Thus, -g0 negates -g.
>
> Level 1 produces minimal information, enough for making backtraces
> in parts of the program that you don’t plan to debug. This includes
> descriptions of functions and external variables, and line number
> tables, but no information about local variables.
>
> Level 3 includes extra information, such as all the macro
> definitions present in the program. Some debuggers support macro
> expansion when you use -g3.
>
> Rustc Codegen manual:
>
> debuginfo
>
> This flag controls the generation of debug information. It takes
> one of the following values:
>
> 0: no debug info at all (the default).
> 1: line tables only.
> 2: full debug info.
>
> I moved CONFIG_DEBUG_INFO_REDUCED into the debug level choice.
>
> This change will make it easier to add another debug info level if
> necessary.
>
> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> Acked-by: Miguel Ojeda <ojeda@kernel.org>
As far as I can tell, this will require updating defconfigs again to
include an explicit 'CONFIG_DEBUG_INFO_DEFAULT=y', right? It might be
nice to do that as part of this change to keep everything working, as
there was some fallout from the last time:
92f89ec1b534 ("powerpc: Restore CONFIG_DEBUG_INFO in defconfigs")
ddd366bf01de ("ARM: defconfig: address renamed CONFIG_DEBUG_INFO=y")
Regardless, I think this is a good change.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
>
> lib/Kconfig.debug | 59 +++++++++++++++++++++++++++++------------------
> 1 file changed, 36 insertions(+), 23 deletions(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index cc90414d492e..ce1faae1a979 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -234,15 +234,10 @@ config DEBUG_INFO
> choice
> prompt "Debug information"
> depends on DEBUG_KERNEL
> + depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502)
> help
> Selecting something other than "None" results in a kernel image
> that will include debugging info resulting in a larger kernel image.
> - This adds debug symbols to the kernel and modules (gcc -g), and
> - is needed if you intend to use kernel crashdump or binary object
> - tools like crash, kgdb, LKCD, gdb, etc on the kernel.
> -
> - Choose which version of DWARF debug info to emit. If unsure,
> - select "Toolchain default".
>
> config DEBUG_INFO_NONE
> bool "Disable debug information"
> @@ -250,10 +245,40 @@ config DEBUG_INFO_NONE
> Do not build the kernel with debugging information, which will
> result in a faster and smaller build.
>
> +config DEBUG_INFO_REDUCED
> + bool "Reduced debugging information"
> + select DEBUG_INFO
> + help
> + If you say Y here compiler is instructed to generate less debugging
> + information for structure types. This means that tools that
> + need full debugging information (like kgdb or systemtap) won't
> + be happy. But if you merely need debugging information to
> + resolve line numbers there is no loss. Advantage is that
> + build directory object sizes shrink dramatically over a full
> + DEBUG_INFO build and compile times are reduced too.
> + Only works with newer gcc versions.
> +
> +config DEBUG_INFO_DEFAULT
> + bool "Default-level debugging information"
> + select DEBUG_INFO
> + help
> + If you say Y here compiler is instructed to generate the default
> + level of debugging information.
> +
> + This adds debug symbols to the kernel and modules (gcc -g), and
> + is needed if you intend to use kernel crashdump or binary object
> + tools like crash, kgdb, LKCD, gdb, etc on the kernel.
> +
> +endchoice # "Debug information"
> +
> +choice
> + prompt "DWARF version"
> + depends on DEBUG_INFO
> + help
> + Which version of DWARF debug info to emit.
> +
> config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
> bool "Rely on the toolchain's implicit default DWARF version"
> - select DEBUG_INFO
> - depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502)
> help
> The implicit default version of DWARF debug info produced by a
> toolchain changes over time.
> @@ -262,9 +287,10 @@ config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
> support newer revisions, and prevent testing newer versions, but
> those should be less common scenarios.
>
> + If unsure, say Y.
> +
> config DEBUG_INFO_DWARF4
> bool "Generate DWARF Version 4 debuginfo"
> - select DEBUG_INFO
> depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)
> help
> Generate DWARF v4 debug info. This requires gcc 4.5+, binutils 2.35.2
> @@ -276,7 +302,6 @@ config DEBUG_INFO_DWARF4
>
> config DEBUG_INFO_DWARF5
> bool "Generate DWARF Version 5 debuginfo"
> - select DEBUG_INFO
> depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)
> help
> Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
> @@ -291,22 +316,10 @@ config DEBUG_INFO_DWARF5
> config if they rely on tooling that has not yet been updated to
> support DWARF Version 5.
>
> -endchoice # "Debug information"
> +endchoice # "DWARF version"
>
> if DEBUG_INFO
>
> -config DEBUG_INFO_REDUCED
> - bool "Reduce debugging information"
> - help
> - If you say Y here gcc is instructed to generate less debugging
> - information for structure types. This means that tools that
> - need full debugging information (like kgdb or systemtap) won't
> - be happy. But if you merely need debugging information to
> - resolve line numbers there is no loss. Advantage is that
> - build directory object sizes shrink dramatically over a full
> - DEBUG_INFO build and compile times are reduced too.
> - Only works with newer gcc versions.
> -
> config DEBUG_INFO_COMPRESSED
> bool "Compressed debugging information"
> depends on $(cc-option,-gz=zlib)
> --
> 2.34.1
>
next prev parent reply other threads:[~2022-10-03 17:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-02 18:11 [PATCH 0/3] Kconfig.debug: make more efforts to fix CONFIG_DEBUG_INFO for Clang+GAS Masahiro Yamada
2022-10-02 18:11 ` [PATCH 1/3] Kconfig.debug: simplify the dependency of DEBUG_INFO_DWARF4/5 Masahiro Yamada
2022-10-03 16:47 ` Nathan Chancellor
2022-10-03 16:53 ` Nick Desaulniers
2022-10-03 19:56 ` Masahiro Yamada
2022-10-02 18:11 ` [PATCH 2/3] Kconfig.debug: add toolchain checks for DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT Masahiro Yamada
2022-10-03 17:10 ` Nathan Chancellor
2022-10-03 20:18 ` Masahiro Yamada
2022-10-03 20:32 ` Nathan Chancellor
2022-10-02 18:11 ` [PATCH 3/3] Kconfig.debug: split debug-level and DWARF-version into separate choices Masahiro Yamada
2022-10-03 17:20 ` Nathan Chancellor [this message]
2022-10-03 20:58 ` Masahiro Yamada
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YzsZzjjJFcPILOji@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox