From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-28.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06128C43470 for ; Wed, 14 Apr 2021 23:47:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D1338611AD for ; Wed, 14 Apr 2021 23:47:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229839AbhDNXrj (ORCPT ); Wed, 14 Apr 2021 19:47:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229573AbhDNXrg (ORCPT ); Wed, 14 Apr 2021 19:47:36 -0400 Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14B5BC06175F for ; Wed, 14 Apr 2021 16:47:13 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id a1so25129218ljp.2 for ; Wed, 14 Apr 2021 16:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+TpZa+C9cCQwz4Q2nu+eQulPH6EC1ZhAKJ0Pt2gzF58=; b=CjmCZvhyG1hOPzQ0l7b1Br0e4i7SFJ8KrImnZRGRP0SCVDXXfHW4HoDlWBvTbq0WSv fcLuenxPR5TSbfjQ5WLbNxs4D/NVnzepr7FK1GKTd+9yxFp2VJ0GJiai7n5rL72Uq1aM k3WkJ5gAaYpFl4qQnWX8ZCTVosqEi7TA2Lv6054ltoIuPK4G4ZQ4jvl6eKT82QnjkBAF Q5ZPhd81n9Xkk9fA61LKnmq+9yejt3s3XqOHeHq+/XeTbgYIGpvlwr19zfoDp+QsqCyQ vHm1OgzZtwmFWKakdNo6gbNopibS26GcSs32BtOUqA4UMcnY0TV3dAeu1Dx9xqoPwCr1 sl9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+TpZa+C9cCQwz4Q2nu+eQulPH6EC1ZhAKJ0Pt2gzF58=; b=EH4NGcU3yjNnXVK5ojTmBavbv48PcaZib41z0boAPqVX/llFb819aaXtkxVokRx7DE tTa9iihc1j8RVI/E5ECsHt2lITe2iQ6EWnieex6UuDUgl7VQyQVKpNqWXemAV0z25OI9 uPBrrb1PW5ptw5Ygxo4IiHyqc+i/0yJd6lMWLgEKTjUhcl4CTw7It8okssuEKw7+nW5t BLnMqk0RFwTGOtWgRuy0U1S/t0rTZWU/zSa5U6mLTQiATDxEdyQ3gxN2MhUZQHEP9Jv2 ybBfAQRdkJZisGU1QyQVjzILCzsGF0Q1HODQXZ/0AcpXVr2F3nGQcJFPoevY3KfCwLsS HijA== X-Gm-Message-State: AOAM5335wUOpslGDWXrs1zLYz7vMeEOtokoH37QUpeXPp66U+qTmdkYm iSlf0anXZkf5D6lwrumVk1jxJW29CaUVkMOcTrPQHA== X-Google-Smtp-Source: ABdhPJx1061aL/GqHoj3QkAEX++DNSP6KXBGITCMLiN6jW2qaQa8bGDJNhOL8TCspjkGwTLyMoKgn+vBboav1U+bOOg= X-Received: by 2002:a2e:b817:: with SMTP id u23mr249392ljo.116.1618444031762; Wed, 14 Apr 2021 16:47:11 -0700 (PDT) MIME-Version: 1.0 References: <20210414184604.23473-1-ojeda@kernel.org> <20210414184604.23473-4-ojeda@kernel.org> In-Reply-To: <20210414184604.23473-4-ojeda@kernel.org> From: Nick Desaulniers Date: Wed, 14 Apr 2021 16:46:59 -0700 Message-ID: Subject: Re: [PATCH 03/13] Makefile: Generate CLANG_FLAGS even in GCC builds To: Miguel Ojeda Cc: Linus Torvalds , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, Linux Kbuild mailing list , Linux Doc Mailing List , LKML , Alex Gaynor , Geoffrey Thomas , Finn Behrens , Adam Bratschi-Kaye , Wedson Almeida Filho Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 14, 2021 at 11:48 AM wrote: > > From: Miguel Ojeda > > To support Rust under GCC-built kernels, we need to save the flags that > would have been passed if the kernel was being compiled with Clang. > > The reason is that bindgen -- the tool we use to generate Rust bindings > to the C side of the kernel -- relies on libclang to parse C. Ideally: > > - bindgen would support a GCC backend (requested at [1]), > > - or the Clang driver would be perfectly compatible with GCC, > including plugins. Unlikely, of course, but perhaps a big > subset of configs may be possible to guarantee to be kept > compatible nevertheless. > > This is also the reason why GCC builds are very experimental and some > configurations may not work (e.g. GCC_PLUGIN_RANDSTRUCT). However, > we keep GCC builds working (for some example configs) in the CI > to avoid diverging/regressing further, so that we are better prepared > for the future when a solution might become available. > > [1] https://github.com/rust-lang/rust-bindgen/issues/1949 > > Link: https://github.com/Rust-for-Linux/linux/issues/167 > > Co-developed-by: Alex Gaynor > Signed-off-by: Alex Gaynor > Co-developed-by: Geoffrey Thomas > Signed-off-by: Geoffrey Thomas > Co-developed-by: Finn Behrens > Signed-off-by: Finn Behrens > Co-developed-by: Adam Bratschi-Kaye > Signed-off-by: Adam Bratschi-Kaye > Co-developed-by: Wedson Almeida Filho > Signed-off-by: Wedson Almeida Filho > Signed-off-by: Miguel Ojeda > --- > Makefile | 27 ++++++++++++++++----------- > 1 file changed, 16 insertions(+), 11 deletions(-) > > diff --git a/Makefile b/Makefile > index d4784d181123..9c75354324ed 100644 > --- a/Makefile > +++ b/Makefile > @@ -559,26 +559,31 @@ ifdef building_out_of_srctree > { echo "# this is build directory, ignore it"; echo "*"; } > .gitignore > endif > > -# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included. > -# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile. > -# CC_VERSION_TEXT is referenced from Kconfig (so it needs export), > -# and from include/config/auto.conf.cmd to detect the compiler upgrade. > -CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g') > +TENTATIVE_CLANG_FLAGS := -Werror=unknown-warning-option > > -ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) > ifneq ($(CROSS_COMPILE),) > -CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > +TENTATIVE_CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > -CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > +TENTATIVE_CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) > endif > ifneq ($(GCC_TOOLCHAIN),) > -CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) > +TENTATIVE_CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN) > endif > ifneq ($(LLVM_IAS),1) > -CLANG_FLAGS += -no-integrated-as > +TENTATIVE_CLANG_FLAGS += -no-integrated-as > endif > -CLANG_FLAGS += -Werror=unknown-warning-option > + > +export TENTATIVE_CLANG_FLAGS I'm ok with this approach, but I'm curious: If the user made a copy of the CLANG_FLAGS variable and modified its copy, would TENTATIVE_CLANG_FLAGS even be necessary? IIUC, TENTATIVE_CLANG_FLAGS is used to filter out certain flags before passing them to bindgen? Or, I'm curious whether you even need to rename this variable (or create a new variable) at all? Might make for a shorter diff if you just keep the existing identifier (CLANG_FLAGS), but create them unconditionally (at least not conditional on CC=clang). > + > +# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included. > +# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile. > +# CC_VERSION_TEXT is referenced from Kconfig (so it needs export), > +# and from include/config/auto.conf.cmd to detect the compiler upgrade. > +CC_VERSION_TEXT = $(shell $(CC) --version 2>/dev/null | head -n 1 | sed 's/\#//g') > + > +ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) > +CLANG_FLAGS += $(TENTATIVE_CLANG_FLAGS) > KBUILD_CFLAGS += $(CLANG_FLAGS) > KBUILD_AFLAGS += $(CLANG_FLAGS) > export CLANG_FLAGS > -- > 2.17.1 > -- Thanks, ~Nick Desaulniers