Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAK7LNAST0Ma4bGGOA_HATzYAmRhZG=x_X=8p_9dKGX7bYc2FMA@mail.gmail.com>
 <20201104005343.4192504-1-ndesaulniers@google.com> <20201104005343.4192504-5-ndesaulniers@google.com>
 <20201124172836.GA346213@rani.riverdale.lan> <CAKwvOdkGvLrPr4pHi4LKCF5t74+wencdy7r38d3k_4pC9pQYwQ@mail.gmail.com>
 <CAKwvOdmEVM67v8PqPWHP-VyGTkQpkWv8FdOTbxQ-7ebvSummMA@mail.gmail.com> <X8psgMuL4jMjP/Oy@rani.riverdale.lan>
In-Reply-To: <X8psgMuL4jMjP/Oy@rani.riverdale.lan>
From:   Nick Desaulniers <ndesaulniers@google.com>
Date:   Thu, 10 Dec 2020 15:18:45 -0800
Message-ID: <CAKwvOd=SbbJptBbv3y39_ZCeTbO0vb_fa5ZbQQ2LUquegzLycg@mail.gmail.com>
Subject: Re: [PATCH v2 4/4] Kbuild: implement support for DWARF v5
To:     Arvind Sankar <nivedita@alum.mit.edu>,
        Masahiro Yamada <masahiroy@kernel.org>
Cc:     Jakub Jelinek <jakub@redhat.com>,
        Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-toolchains@vger.kernel.org,
        clang-built-linux <clang-built-linux@googlegroups.com>,
        Fangrui Song <maskray@google.com>,
        Nathan Chancellor <natechancellor@gmail.com>,
        Sedat Dilek <sedat.dilek@gmail.com>,
        Dmitry Golovin <dima@golovin.in>,
        Alistair Delva <adelva@google.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Dec 4, 2020 at 9:06 AM Arvind Sankar <nivedita@alum.mit.edu> wrote:
>
> On Thu, Dec 03, 2020 at 03:28:14PM -0800, Nick Desaulniers wrote:
> > On Thu, Dec 3, 2020 at 3:22 PM Nick Desaulniers <ndesaulniers@google.com> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 9:28 AM Arvind Sankar <nivedita@alum.mit.edu> wrote:
> > > >
> > > > On Tue, Nov 03, 2020 at 04:53:43PM -0800, Nick Desaulniers wrote:
> > > > > DWARF v5 is the latest standard of the DWARF debug info format.
> > > > >
> > > > > Feature detection of DWARF5 is onerous, especially given that we've
> > > > > removed $(AS), so we must query $(CC) for DWARF5 assembler directive
> > > > > support.  GNU `as` only recently gained support for specifying
> > > > > -gdwarf-5.
> > > >
> > > > With gcc, using -gdwarf-5 even without -Wa,--gdwarf-5 results in
> > > > considerably smaller debug info. gcc does not seem to generate the .file 0
> > > > directive that causes older GNU as to barf.
> > > >
> > > > Should the assembler support check be restricted to CC_IS_CLANG?
> > >
> > > No, because if LLVM_IAS=1 then the assembler support need not be checked.
> >
> > Also, if your version of GCC supports DWARF Version 5, but your
> > version of GAS does not, then I'm more inclined to not allow
> > CONFIG_DEBUG_INFO_DWARF5 to be selectable, rather than mix and match
> > or partially support this for one but not the other.  Either all tools
> > used support DWARF 5, or you don't get to use DWARF 5.
> >
>
> Why? Does this actually cause any problems?
>
> It seems like the options for gcc can actually be very straightforward:
> you just need a cc-option check, and then add -gdwarf-N to both CFLAGS
> and AFLAGS and you're done.  Adding the -Wa flag is superfluous and
> carries the risk of interfering with what the compiler driver does. Just
> let the gcc driver handle the details.
>
> Clang/IAS is almost as straightforward, with the only additional edge
> case being that for assembler files, DWARF 2 doesn't work, so the CFLAGS
> is the same -gdwarf-N, but AFLAGS gets -gdwarf-N only if N > 2.
>
> The messy case is only Clang/IAS=0, which needs to check the support
> from the external assembler, and needs CFLAGS of -gdwarf-N and AFLAGS of
> -Wa,--gdwarf-N, because Clang doesn't pass that option on to an external
> assembler. This is why I was asking if the assembler support check can
> be restricted to CC_IS_CLANG: nothing but Clang/IAS=0 actually requires
> that check.

Oh, I see. Yeah, that might be a nicer approach.  What should we do in
the case of gcc < 7 though, where -gdwarf-5 won't produce DWARF v5?
Maybe that's ok, but the intent behind the Kconfig check was to
prevent the option from being selectable if the tools do not support
it.  Maybe it's more flexible to pass the arguments along, and hope
for the best?

As a gcc-5 user, I might be surprised if I chose
CONFIG_DEBUG_INFO_DWARF5 if what I got was not actually DWARF v5; it
does violate the principle of least surprise.  Maybe that doesn't
matter though?
-- 
Thanks,
~Nick Desaulniers