linux-kernel - Re: [PATCH] kconfig: prefer toolchain default for debug information choice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b204ba9d-beaf-4d8b-9bc3-22d88acf8b6a@t-8ch.de>
Date: Mon, 25 Nov 2024 09:45:48 +0100
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, 
	linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas@...sle.eu>, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH] kconfig: prefer toolchain default for debug information
 choice

On 2024-11-25 10:36:45+0900, Masahiro Yamada wrote:
> On Mon, Nov 25, 2024 at 10:27 AM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Mon, Nov 25, 2024 at 12:59 AM Thomas Weißschuh <linux@...ssschuh.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/