mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Thomas Weißschuh" <linux@weissschuh.net>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 linux-kernel@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	 Nicolas Schier <nicolas@fjasle.eu>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] kconfig: prefer toolchain default for debug information choice
Date: Mon, 25 Nov 2024 09:45:48 +0100	[thread overview]
Message-ID: <b204ba9d-beaf-4d8b-9bc3-22d88acf8b6a@t-8ch.de> (raw)
In-Reply-To: <CAK7LNATgCBzesiPzyQarGY8308jZ1rC5zC2e6xZCw0UmaB=qyw@mail.gmail.com>

On 2024-11-25 10:36:45+0900, Masahiro Yamada wrote:
> On Mon, Nov 25, 2024 at 10:27 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Mon, Nov 25, 2024 at 12:59 AM Thomas Weißschuh <linux@weissschuh.net> wrote:
> > >
> > > Kconfig by default chooses the first entry of a choice setting.
> > > For the "debug information" choice this is DEBUG_INFO_NONE which
> > > disables debug information completely.
> > >
> > > The kconfig choice itself recommends to use "Toolchain default":
> > >
> > >         Choose which version of DWARF debug info to emit. If unsure,
> > >         select "Toolchain default".
> > >
> > > Align the actual configuration with the recommendation by providing an
> > > explicit default.
> > >
> > > This also enables more codepaths from allmodconfig/allyesconfig which
> > > depend on debug information being available.
> >
> > Please give me some examples for "more codepaths" enabled by DEBUG_INFO
> > because this is the opposite to the previous decision.

It's really only the BTF stuff. IIRC there was some very minor
arch-specific things, too but these should not matter.

> > Commit f9b3cd24578401e7a392974b3353277286e49cee mentions:
> >
> >   all*config target ends up taking much longer and the output is much larger.
> >   Having this be "default off" makes sense.
> >
> >
> >
> > allmodconfig is often used for compile testing in CI/CD.
> > We need to see the sufficient gain that sacrifices
> > the build speed.

Thanks for that pointer.
It feels wrong to me to deviate from the pure meaning of "allyesconfig"
for one specific usecase.
The CI systems presumably have to adapt the configs to various
constraint anyways (the thread in [0] comes to mind).
So they can disable debuginfo if they so desire.

Especially as the kconfig help text explicitly recommends to enable this
if unsure.

> Presumably, DEBUG_INFO_BTF is the one because you submitted
> some patches at the same time.

Yes, it's about DEBUG_INFO_BTF.
But it was not the first series where the BTF stuff was surprisingly not
compiled in an all{yes,mod}config.

> Are there some compile errors that are not detected
> when DEBUG_INFO_BTF is disabled?

Not in the current kernel, these would have been detected by at least
the randconfig builds.

[0] https://lore.kernel.org/lkml/202411221744.1a298e1e-lkp@intel.com/

  reply	other threads:[~2024-11-25  8:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-24 15:58 Thomas Weißschuh
2024-11-25  1:27 ` Masahiro Yamada
2024-11-25  1:36   ` Masahiro Yamada
2024-11-25  8:45     ` Thomas Weißschuh [this message]
2024-11-25 14:52 ` Nathan Chancellor
2024-11-25 15:46   ` Thomas Weißschuh
2024-11-25 18:58     ` Nathan Chancellor
2024-12-01  8:58       ` Thomas Weißschuh

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=b204ba9d-beaf-4d8b-9bc3-22d88acf8b6a@t-8ch.de \
    --to=linux@weissschuh.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --cc=nathan@kernel.org \
    --cc=nicolas@fjasle.eu \
    /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

all inboxes | Powered by JetHome®