Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp758565rwe; Fri, 26 Aug 2022 14:01:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR6quS726rOF2sZxlkEI1xdorowRPJFL81VPSK7FufWm87k14/Nbo8kU9TUTBGl0DbeNVRO2 X-Received: by 2002:a17:902:e752:b0:173:1346:393f with SMTP id p18-20020a170902e75200b001731346393fmr5296754plf.153.1661547660085; Fri, 26 Aug 2022 14:01:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661547660; cv=none; d=google.com; s=arc-20160816; b=H0GnpCnCnFsFs7dPAEcKPoRL2E+meICylA6SMGA+d6pKcYxAmF4ebNAaeciZFjaTrH h6RosQPYuhwZSSrFm4177NTrhkI5Dz1U54lUbtC0eNGJ4n3ruYJyAUuwBj7S4T0tn2tq za7xAHbeHOAv5WoDconbKZ67/VzI16AiMJNfj5ce+BIbawaqH5KAJ/Ur3gFib0tXBTrU mqoUbo95INDiLyOOVD5JDC/Gk0BqHnsbkrqjIE+qY89v3vJTJs3BeQGlkUgbbjSWYS4g d1JrmPwS6tjaMooW1Vsi8i0RiN494IqxzElk3jPFYKWmHwO0jpvqWyJGYcWVVotELnTU eQ+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=P9zRTXvNypp3XLQggkQTXRwQu3WlNLsiD9EHNuXARTg=; b=dZHUJyqRDd9tsMUM/nSD2B9GCjHJaClvnIOxd/rNUoc781UJK52QPqoMBRbOKYEE4V CXy/bJnYD0BnoH+uB4LZm6BYWcd4FNYdc93TD5Q/w533KZDeFcpA2DVaUKmT5wTvwJyB bx2Vp4YlTj2URY2Jl/LNEUCFbaDbf9JbC0WKJCM12lLtUJFa0DTLXl1jmOP8d3qud3n2 NJ6/L4BheC4P5EgWwaOfb+dF2G+w2iDIaa8sy9QdbDnKt6ZiPROS2T9IHhWUBIi3AH3j +LGlbi/agLZGdy1CN39v5QKXTTILxdCMK2FNDYDTSbW+YWd7/xvKbX7gDBnWqV8qNAvY tL4w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=La0x9Sjq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i8-20020a17090332c800b0016d3240c41bsi2578549plr.159.2022.08.26.14.00.44; Fri, 26 Aug 2022 14:01:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=La0x9Sjq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344734AbiHZUlv (ORCPT + 99 others); Fri, 26 Aug 2022 16:41:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344959AbiHZUlh (ORCPT ); Fri, 26 Aug 2022 16:41:37 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8D9BEDB7F6 for ; Fri, 26 Aug 2022 13:41:34 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-324ec5a9e97so64441557b3.7 for ; Fri, 26 Aug 2022 13:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=P9zRTXvNypp3XLQggkQTXRwQu3WlNLsiD9EHNuXARTg=; b=La0x9SjqRvdzB4vrHoyKFtUVY2OoiypUYeaR78qLZ1vc0Nwu/4BSAIHNm5vqUngnKI 4BZMs1MLaYX3We+ieWOWrIPjLiUTUM7q+lNsmXJtQ66T5JJFlSHM15jB1LAJf2FROLjB /ZFOXLO8zJT7cLYDpJkeiAEVbeqi5uinaep2zlxBJ5IaQxw2JDoOt0on08QyfNVdljdH pVERyUPLTkGofJNvPCIG2JNKsIX8UkDN7akdKRFln29ViEQtCyxqyLHZ9URilv8T+YV/ llMYnpXHX9q4GlGyyGq+DPmoXdzD7rHkb8LhmMaFp2w5R5qc0OB5efh/jl0E9HCwXBkT 1GHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=P9zRTXvNypp3XLQggkQTXRwQu3WlNLsiD9EHNuXARTg=; b=U/jJIjFGQwzU4vLhuhtgSaEPPpHz67HK5VGf31MTaw0cslkM+1wXTne6gLGXNbP0me LoGuwbAy5ah6nWlQMPmberWL4ZjWd81T9GEPyCKGT6XgyWwpEJ9YCymfTJyXsyud5NEm K9WzQj+eOyJpm5QRW+T30TbFBmvODmcC+QcvfYYp6sK+uiWCVCYWwvlJYizqb3ogKh2X T/R/teV3Tw4eBBEitC9b6IPeblILy1aKD59dziBXgBXoJCWtjuw7VGLU7aUYucYqIuvV Yzyi6AdHst8J52mu7895saVdBSBp1yZdZFtZwSbATm6F5H+kMzNBrjpJapYuz/oK9h5X 80ng== X-Gm-Message-State: ACgBeo0ykEzPlJSGJqUY43eBtSk5k+ocRc7428ZQua5szchNOCS6Jlti kEaT0WnCNWkJKgXqbF00njEI+cGkIOU25tibqdL/ X-Received: by 2002:a25:8550:0:b0:691:11f9:41dd with SMTP id f16-20020a258550000000b0069111f941ddmr1315287ybn.600.1661546493585; Fri, 26 Aug 2022 13:41:33 -0700 (PDT) MIME-Version: 1.0 References: <20220826181035.859042-1-ndesaulniers@google.com> <20220826181035.859042-3-ndesaulniers@google.com> In-Reply-To: From: Bill Wendling Date: Fri, 26 Aug 2022 13:41:22 -0700 Message-ID: Subject: Re: [PATCH 2/3] Makefile.debug: re-enable debug info for .S files To: Nick Desaulniers Cc: Masahiro Yamada , Michal Marek , Nathan Chancellor , Tom Rix , Linux Kbuild mailing list , LKML , clang-built-linux , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Dmitrii Bundin , Fangrui Song , Alexey Alexandrov , Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Aug 26, 2022 at 1:16 PM Nick Desaulniers wrote: > > On Fri, Aug 26, 2022 at 12:52 PM Nick Desaulniers > wrote: > > > > On Fri, Aug 26, 2022 at 11:41 AM Bill Wendling wrote: > > > > > > On Fri, Aug 26, 2022 at 11:10 AM Nick Desaulniers > > > wrote: > > > > > > > > Alexey reported that the fraction of unknown filename instances in > > > > kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down > > > > to assembler defined symbols, which regressed as a result of: > > > > > > > > commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") > > > > > > > > In that commit, I allude to restoring debug info for assembler defined > > > > symbols in a follow up patch, but it seems I forgot to do so in > > > > > > > > commit a66049e2cf0e ("Kbuild: make DWARF version a choice") > > > > > > > > This patch does a few things: > > > > 1. Add -g to KBUILD_AFLAGS. This will instruct the compiler to instruct > > > > the assembler to emit debug info. But this can cause an issue for > > > > folks using a newer compiler but older assembler, because the > > > > implicit default DWARF version changed from v4 to v5 in gcc-11 and > > > > clang-14. > > > > 2. If the user is using CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT, use a > > > > version check to explicitly set -Wa,-gdwarf- for the > > > > assembler. There's another problem with this; GAS only gained support > > > > for explicit DWARF versions 3-5 in the 2.36 GNU binutils release. > > > > 3. Wrap -Wa,-gdwarf- in as-option call to test whether the > > > > assembler supports that explicit DWARF version. > > > > > > > > Link: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31bf18645d98b4d3d7357353be840e320649a67d > > > > Fixes: b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1") > > > > Reported-by: Alexey Alexandrov > > > > Reported-by: Bill Wendling > > > > Reported-by: Greg Thelen > > > > Signed-off-by: Nick Desaulniers > > > > --- > > > > scripts/Makefile.debug | 22 ++++++++++++++++++---- > > > > 1 file changed, 18 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/scripts/Makefile.debug b/scripts/Makefile.debug > > > > index 9f39b0130551..a7a6da7f6e7d 100644 > > > > --- a/scripts/Makefile.debug > > > > +++ b/scripts/Makefile.debug > > > > @@ -4,18 +4,32 @@ ifdef CONFIG_DEBUG_INFO_SPLIT > > > > DEBUG_CFLAGS += -gsplit-dwarf > > > > else > > > > DEBUG_CFLAGS += -g > > > > +KBUILD_AFLAGS += -g > > > > endif > > > > > > > > -ifndef CONFIG_AS_IS_LLVM > > > > -KBUILD_AFLAGS += -Wa,-gdwarf-2 > > > > +ifdef CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > > > > +# gcc-11+, clang-14+ > > > > +ifeq ($(shell [ $(CONFIG_GCC_VERSION) -ge 110000 -o $(CONFIG_CLANG_VERSION) -ge 140000 ] && echo y),y) > > > > > > Do you think this would be better as a macro? Maybe something like: > > > > > > if $(call cc-min-version,110000,140000) > > > > > > where the first argument is GCC's min version and second Clang's min > > > version. It would be more readable and reusable. > > > > Yeah! > > > > I was looking at cc-ifversion, which has a bug in that it specifically > > uses CONFIG_GCC_VERSION. I think I sent a series maybe a year or two > > ago trying to remove all users of that macro; I think most landed but > > not all and I never pursued it to completion. Also, I think there's > > one user remaining in the AMDGPU drivers; looks like they're been > > reducing their dependency on that SIMD hack I wrote for them years ago > > after propagating it to parts of their tree, but one user remains. > > Perhaps I can just open code it there, or replace it with something > > new like you suggest. > > > > Such a macro would need to consider whether CC_IS_GCC vs CC_IS_CLANG; > > I could imagine we might need a version check for both, or just one of > > the two compilers. > > > > Ugh, logical OR in GNU make is supported by use of the filter macro...yuck. > > > > ifneq ($(filter y, $(call gcc-min-version, 110000), $(call > > clang-min-version, 140000),) > > # add gcc-11+, clang-14+ flag > > endif > > > > or maybe as you suggest: > > > > ifneq ($(call cc-min-version,110000,140000),) > > # add gcc-11+, clang-14+ flag > > endif > > > > where the newly minted cc-min-version is implemented in terms of the > > newly minted gcc-min-version and clang-min-version. Then I can use > > cc-min-version in this series, and replace cc-ifversion in AMDGPU with > > gcc-min-version. That way, we create composable wrappers that are > > readable and reusable. > > RFC: > ``` > diff --git a/scripts/Makefile.compiler b/scripts/Makefile.compiler > index d1739f0d3ce3..4809a4c9e5f2 100644 > --- a/scripts/Makefile.compiler > +++ b/scripts/Makefile.compiler > @@ -65,6 +65,19 @@ cc-disable-warning = $(call try-run,\ > # Usage: EXTRA_CFLAGS += $(call cc-ifversion, -lt, 0402, -O1) > cc-ifversion = $(shell [ $(CONFIG_GCC_VERSION)0 $(1) $(2)000 ] && > echo $(3) || echo $(4)) > > +# gcc-min-version > +# Usage: cflags-$(call gcc-min-version, 70100) += -foo > +gcc-min-version = $(shell [ $(CONFIG_GCC_VERSION) -ge $(1) ] && echo y) > + > +# clang-min-version > +# Usage: cflags-$(call clang-min-version, 110000) += -foo > +clang-min-version = $(shell [ $(CONFIG_CLANG_VERSION) -ge $(1) ] && echo y) > + > +# cc-min-version > +# Usage: cflags-$(call cc-min-version, 701000, 110000) > +# ^ GCC ^ Clang > +cc-min-version = $(filter y, $(call gcc-min-version, $(1)), $(call > clang-min-version, $(2))) > + > # ld-option > # Usage: KBUILD_LDFLAGS += $(call ld-option, -X, -Y) > ld-option = $(call try-run, $(LD) $(KBUILD_LDFLAGS) $(1) -v,$(1),$(2),$(3)) > diff --git a/scripts/Makefile.debug b/scripts/Makefile.debug > index 0f9912f7bd4c..80c84f746219 100644 > --- a/scripts/Makefile.debug > +++ b/scripts/Makefile.debug > @@ -7,7 +7,7 @@ endif > > ifdef CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > # gcc-11+, clang-14+ > -ifeq ($(shell [ $(CONFIG_GCC_VERSION) -ge 110000 -o > $(CONFIG_CLANG_VERSION) -ge 140000 ] && echo y),y) > +ifeq ($(call cc-min-version, 110000, 140000), y) > dwarf-version-y := 5 > else > dwarf-version-y := 4 > > ``` > > I'd keep the replacement of cc-ifversion with gcc-min-version as a > distinct child patch, since I don't care about backports for that (and > there's probably more cc-ifversion users the further back you go) but > I think we might want cc-min-version in stable. > > Technically, the above should also update > Documentation/kbuild/makefiles.rst; but I'm just testing this works; > it seems to. > > Oh, it looks like cc-ifversion both permits checking max-version and > min version. But we can implement -ge and -lt with just one or the > other: > > ``` > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile > b/drivers/gpu/drm/amd/display/dc/dml/Makefile > index 86a3b5bfd699..17e8fd42d0a5 100644 > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile > @@ -34,7 +34,7 @@ dml_ccflags := -mhard-float -maltivec > endif > > ifdef CONFIG_CC_IS_GCC > -ifeq ($(call cc-ifversion, -lt, 0701, y), y) > +ifeq ($(call gcc-min-version, 70100),) I think for this you want "gcc-max-version". > IS_OLD_GCC = 1 > endif > endif > ``` > > Thoughts? > I like this idea. Modifying "cc-ifversion" would be great, but you'd have to somehow specify the checking versions for both gcc and clang in the macro, and that's messy given the number of arguments that already exist. It might be possible instead to implement "cc-ifversion" in terms of the "*-{max,min}-version" macros. -bw > > > > > > > > -bw > > > > > > > +dwarf-version-y := 5 > > > > +else > > > > +dwarf-version-y := 4 > > > > endif > > > > - > > > > -ifndef CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > > > > +else # !CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT > > > > dwarf-version-$(CONFIG_DEBUG_INFO_DWARF4) := 4 > > > > dwarf-version-$(CONFIG_DEBUG_INFO_DWARF5) := 5 > > > > DEBUG_CFLAGS += -gdwarf-$(dwarf-version-y) > > > > endif > > > > > > > > +# Binutils 2.35+ (or clang) required for -gdwarf-{4|5}. > > > > +# https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31bf18645d98b4d3d7357353be840e320649a67d > > > > +ifneq ($(call as-option,-Wa$(comma)-gdwarf-$(dwarf-version-y)),) > > > > +KBUILD_AFLAGS += -Wa,-gdwarf-$(dwarf-version-y) > > > > +else > > > > +ifndef CONFIG_AS_IS_LLVM > > > > +KBUILD_AFLAGS += -Wa,-gdwarf-2 > > > > +endif > > > > +endif > > > > + > > > > ifdef CONFIG_DEBUG_INFO_REDUCED > > > > DEBUG_CFLAGS += -fno-var-tracking > > > > ifdef CONFIG_CC_IS_GCC > > > > -- > > > > 2.37.2.672.g94769d06f0-goog > > > > > > > > > > > > -- > > Thanks, > > ~Nick Desaulniers > > > > -- > Thanks, > ~Nick Desaulniers