All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitrii Bundin <dmitrii.bundin.a@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Eric Dumazet <edumazet@google.com>,
	Isabella Basso <isabbasso@riseup.net>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Fangrui Song <maskray@google.com>,
	Michal Marek <michal.lkml@markovi.net>,
	Nathan Chancellor <nathan@kernel.org>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>,
	Vlastimil Babka <vbabka@suse.cz>
Subject: Re: [PATCH v3] kbuild: add debug level and macro defs options
Date: Sat, 20 Aug 2022 01:52:04 +0300	[thread overview]
Message-ID: <CANXV_Xw2wzwDdJkyV1nHPQm2JTt48SLrNc7YwrfcxOwuFA-z3w@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOdnnSAozX8bQ9HeSw12BV9OjpzyDmXk_BGczjVVQNN+7tQ@mail.gmail.com>

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

  reply	other threads:[~2022-08-19 22:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-14  0:20 [PATCH v2] kbuild: add configurable debug info level Dmitrii Bundin
2022-08-14  2:01 ` Masahiro Yamada
2022-08-14  5:31   ` Fangrui Song
2022-08-14 18:58     ` Masahiro Yamada
2022-08-14 19:17     ` Dmitrii Bundin
2022-08-15  1:33       ` [PATCH v3] kbuild: add debug level and macro defs options Dmitrii Bundin
2022-08-18  4:13         ` Masahiro Yamada
2022-08-18 18:57           ` Dmitrii Bundin
2022-08-19 17:42         ` Nick Desaulniers
2022-08-19 22:52           ` Dmitrii Bundin [this message]
2022-08-22 16:45             ` Nick Desaulniers
2022-08-22 21:36               ` Nick Desaulniers
2022-08-22 22:42                 ` Dmitrii Bundin
2022-08-24 23:25                   ` Nick Desaulniers
2022-09-29 21:06                   ` Masahiro Yamada
2022-09-30  9:11                     ` Masahiro Yamada
2022-10-08  7:24                       ` Dmitrii Bundin
2022-08-23  6:06             ` Peter Zijlstra

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=CANXV_Xw2wzwDdJkyV1nHPQm2JTt48SLrNc7YwrfcxOwuFA-z3w@mail.gmail.com \
    --to=dmitrii.bundin.a@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=edumazet@google.com \
    --cc=isabbasso@riseup.net \
    --cc=jpoimboe@kernel.org \
    --cc=keescook@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=masahiroy@kernel.org \
    --cc=maskray@google.com \
    --cc=michal.lkml@markovi.net \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=vbabka@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.