From: Nick Desaulniers <ndesaulniers@google.com>
To: Mark Wielaard <mark@klomp.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
Nathan Chancellor <natechancellor@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Sedat Dilek <sedat.dilek@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Jakub Jelinek <jakub@redhat.com>,
Fangrui Song <maskray@google.com>,
Caroline Tice <cmtice@google.com>,
Nick Clifton <nickc@redhat.com>, Yonghong Song <yhs@fb.com>,
Jiri Olsa <jolsa@kernel.org>, Andrii Nakryiko <andrii@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Arvind Sankar <nivedita@alum.mit.edu>,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH v7 1/2] Kbuild: make DWARF version a choice
Date: Thu, 4 Feb 2021 11:18:44 -0800 [thread overview]
Message-ID: <CAKwvOdm0O8m_+mxy7Z91Lu=Hzf6-DyCdAjMOsCRiMmNis4Pd2A@mail.gmail.com> (raw)
In-Reply-To: <20210204103946.GA14802@wildebeest.org>
On Thu, Feb 4, 2021 at 2:41 AM Mark Wielaard <mark@klomp.org> wrote:
>
> Hi Nick,
>
> On Fri, Jan 29, 2021 at 04:44:00PM -0800, Nick Desaulniers wrote:
> > Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice which is
> > the default. Does so in a way that's forward compatible with existing
> > configs, and makes adding future versions more straightforward.
> >
> > GCC since ~4.8 has defaulted to this DWARF version implicitly.
>
> And since GCC 11 it defaults to DWARF version 5.
>
> It would be better to set the default to the DWARF version that the
> compiler generates. So if the user doesn't select any version then it
> should default to just -g (or -gdwarf).
I disagree.
https://lore.kernel.org/lkml/CAKwvOdk0zxewEOaFuqK0aSMz3vKNzDOgmez=-Dae4+bodsSg5w@mail.gmail.com/
"""
I agree that this patch takes away the compiler vendor's choice as to
what the implicit default choice is for dwarf version for the kernel.
(We, the Linux kernel, do so already for implicit default -std=gnuc*
as well). ...
But I'm
going to suggest we follow the Zen of Python: explicit is better than
implicit.
"""
We have a number of in tree and out of tree DWARF consumers that
aren't ready for DWARF v5. Kernel developers need a way to disable
DWARF v5 until their dependencies are deployed or more widely
available.
I'm happy to consider eventually moving the default DWARF version for
the kernel to v5, and ideas for how to wean developers off of v4, but
I don't think forcing v5 on kernel developers right now is the most
delicate approach.
--
Thanks,
~Nick Desaulniers
next prev parent reply other threads:[~2021-02-04 19:20 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-30 0:43 [PATCH v7 0/2] Kbuild: DWARF v5 support Nick Desaulniers
2021-01-30 0:44 ` [PATCH v7 1/2] Kbuild: make DWARF version a choice Nick Desaulniers
2021-01-30 1:52 ` Nathan Chancellor
2021-02-03 22:23 ` Masahiro Yamada
2021-02-03 22:25 ` Masahiro Yamada
2021-02-03 23:16 ` Nick Desaulniers
2021-02-04 0:29 ` Masahiro Yamada
2021-02-04 6:15 ` Nick Desaulniers
2021-02-04 3:32 ` Fangrui Song
2021-02-04 6:08 ` Nick Desaulniers
2021-02-04 6:13 ` Nick Desaulniers
2021-02-04 10:39 ` Mark Wielaard
2021-02-04 19:18 ` Nick Desaulniers [this message]
2021-02-04 19:56 ` Mark Wielaard
2021-02-04 20:04 ` Nick Desaulniers
2021-02-04 20:28 ` Mark Wielaard
2021-02-04 22:06 ` Nick Desaulniers
2021-02-04 22:36 ` Fangrui Song
2021-02-05 12:49 ` Mark Wielaard
2021-02-05 21:18 ` Nick Desaulniers
2021-02-06 15:11 ` Mark Wielaard
2021-01-30 0:44 ` [PATCH v7 2/2] Kbuild: implement support for DWARF v5 Nick Desaulniers
2021-01-30 1:53 ` Nathan Chancellor
2021-01-30 23:10 ` Sedat Dilek
2021-01-30 23:39 ` Sedat Dilek
2021-01-31 0:37 ` Fāng-ruì Sòng
2021-01-31 0:39 ` Sedat Dilek
2021-02-03 23:06 ` Masahiro Yamada
2021-02-03 23:27 ` Nick Desaulniers
2021-02-04 0:33 ` Masahiro Yamada
2021-02-03 23:36 ` Jakub Jelinek
2021-02-04 0:33 ` Masahiro Yamada
2021-01-30 23:59 ` [PATCH v7 0/2] Kbuild: DWARF v5 support Sedat Dilek
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='CAKwvOdm0O8m_+mxy7Z91Lu=Hzf6-DyCdAjMOsCRiMmNis4Pd2A@mail.gmail.com' \
--to=ndesaulniers@google.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=clang-built-linux@googlegroups.com \
--cc=cmtice@google.com \
--cc=jakub@redhat.com \
--cc=jolsa@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@klomp.org \
--cc=masahiroy@kernel.org \
--cc=maskray@google.com \
--cc=natechancellor@gmail.com \
--cc=nathan@kernel.org \
--cc=nickc@redhat.com \
--cc=nivedita@alum.mit.edu \
--cc=sedat.dilek@gmail.com \
--cc=yhs@fb.com \
/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;
as well as URLs for NNTP newsgroup(s).