Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp135370ybh; Tue, 21 Jul 2020 18:40:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjxkbdc2mt2v6AGepp8+eI8fJol0LHF1N9Z1Ssv+0wLUiF0e6jUuTW0toAqAmIhT40FZ2O X-Received: by 2002:a05:6402:16c2:: with SMTP id r2mr28109147edx.127.1595382020226; Tue, 21 Jul 2020 18:40:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595382020; cv=none; d=google.com; s=arc-20160816; b=ADzXqOvAKUqCzSxcK0l9+Q6+tPv55JepIrgiRpvkWZIZnWHV7toUpGwVTcCuQ9NmHR P87mxF2cF2Mxhtq+Yv+pGg2XaJAZX+sEB+iAU1u+2YSlPHKbwFHey3R+dKBKpWDTTqF8 nQW12/aMqR4KhIchpNaSA7rnV1J1hmNlB8uqpSF0IuvkDKWUcSObO7i5Ob5smnot8qp2 3MglXM3cG5sSMGIOW8JHADR45r1bt7kFl4xktE6Lf9x7M2F7eEAYJKydaiWhFFfGD62e wYQ5sMtJKRq2sVgEWWrkcQa632Kat3FvsrmAfM4TJYP1FQjyb16fSo0HvnEa5ADvJOMT Ssug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature:dkim-filter; bh=8OlTIawxGJAnm7U5ijTKoZc7UIGiiqP4rmftbHnofNI=; b=xxU0W45OsuCAorj2Ylf9D7hG7PvhxQo9x6uwshg7oPOhX8DH42uLKqH6SrDneS94ZE zZY/y8ar58TWuu+rvyjAUkbL5fCghw99JEM2/xTQDGtlcw5rAQwouQKQZUiH/FtgNdAP wc4J5iuVbL2gu2qRnkOLcZFLtiAHy2Eqy0Qo9hfaNq6Ml27ndPoF9Vqxk24VcFVk2Ql5 MhxFqeque00zE6QP+M2TVtIE7CVd6M9zho3AKoInTByjFBD9nR4pDGHYdll+tLCytTFT sLr27S/TJlH5nKNUnQq8ckBtXlkE3KGq4RuKTRtXwR6yH4JPPjXTbmzb6OenPkyO58o2 qJ9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=ZUxeHj7Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h6si14620722ejq.405.2020.07.21.18.39.54; Tue, 21 Jul 2020 18:40:20 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=ZUxeHj7Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731620AbgGVBhf (ORCPT + 99 others); Tue, 21 Jul 2020 21:37:35 -0400 Received: from conssluserg-05.nifty.com ([210.131.2.90]:63696 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727795AbgGVBhe (ORCPT ); Tue, 21 Jul 2020 21:37:34 -0400 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (authenticated) by conssluserg-05.nifty.com with ESMTP id 06M1b7vJ023564; Wed, 22 Jul 2020 10:37:08 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 06M1b7vJ023564 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1595381828; bh=8OlTIawxGJAnm7U5ijTKoZc7UIGiiqP4rmftbHnofNI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZUxeHj7ZEvTdAgSmI7hz3a0KDXXy21oQcM/eK3sGrJoHajByuQ65L96gho7FWvJay 6WcQkMFtMyYg2sCpZnQl11elEU4Kgd2nZv2uM4J1lL5GeAzMKL5AKYmmwkejt/04EO sPe9bCn8NYiF7SrOiD4OpU3dGMJ0HkjU0ved7PQlHduZWrh6W+VPgjPYnECspR4FO7 DVbepuMqQtlt6XAGi0L74SAuwmybrYxnNcAlZT3fKNmDWGCLwXbvRv1Mm2b03O3sPI 0okPuZM36daDhmbHtDjjgNWqImWw75e1y4aXKTsD8Gne8SStnV8ynnE3hgl8Xh7iW5 Tm83DhZ/Sr0zQ== X-Nifty-SrcIP: [209.85.222.43] Received: by mail-ua1-f43.google.com with SMTP id i24so125881uak.3; Tue, 21 Jul 2020 18:37:07 -0700 (PDT) X-Gm-Message-State: AOAM531yvKv9Ssp7rx3TnGMUEXdTRTKY4ljZ7hDQKm2kILTQ6Wd9YfQ8 arfTnIP3re+MDW6S+2u2b9266pX2QEHAp5iNn1U= X-Received: by 2002:ab0:48:: with SMTP id 66mr23303088uai.40.1595381826755; Tue, 21 Jul 2020 18:37:06 -0700 (PDT) MIME-Version: 1.0 References: <20200721173125.1273884-1-maskray@google.com> <20200722001424.qor3up6357jjsbia@google.com> In-Reply-To: <20200722001424.qor3up6357jjsbia@google.com> From: Masahiro Yamada Date: Wed, 22 Jul 2020 10:36:30 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3] Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation To: Fangrui Song Cc: Michal Marek , Linux Kbuild mailing list , Linux Kernel Mailing List , clang-built-linux , Jian Cai , Bill Wendling , Manoj Gupta , stable , Nathan Chancellor , Nick Desaulniers Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 22, 2020 at 9:14 AM Fangrui Song wrote: > > On 2020-07-22, Masahiro Yamada wrote: > >On Wed, Jul 22, 2020 at 2:31 AM 'Fangrui Song' via Clang Built Linux > > wrote: > >> > >> When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if > >> $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, > >> GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to > >> /usr/bin/ and Clang as of 11 will search for both > >> $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. > >> > >> GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, > >> $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, > >> $(prefix)aarch64-linux-gnu/$needle rarely contains executables. > >> > >> To better model how GCC's -B/--prefix takes in effect in practice, newer > >> Clang (since > >> https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) > >> only searches for $(prefix)$needle. Currently it will find /usr/bin/as > >> instead of /usr/bin/aarch64-linux-gnu-as. > >> > >> Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE) > >> (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the > >> appropriate cross compiling GNU as (when -no-integrated-as is in > >> effect). > >> > >> Cc: stable@vger.kernel.org > >> Reported-by: Nathan Chancellor > >> Signed-off-by: Fangrui Song > >> Reviewed-by: Nathan Chancellor > >> Tested-by: Nathan Chancellor > >> Tested-by: Nick Desaulniers > >> Link: https://github.com/ClangBuiltLinux/linux/issues/1099 > >> --- > >> Changes in v2: > >> * Updated description to add tags and the llvm-project commit link. > >> * Fixed a typo. > >> > >> Changes in v3: > >> * Add Cc: stable@vger.kernel.org > >> --- > >> Makefile | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/Makefile b/Makefile > >> index 0b5f8538bde5..3ac83e375b61 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -567,7 +567,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),) > >> ifneq ($(CROSS_COMPILE),) > >> CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > >> GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > >> -CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR) > >> +CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(CROSS_COMPILE) > > > > > > > >CROSS_COMPILE may contain the directory path > >to the cross toolchains. > > > > > >For example, I use aarch64-linux-gnu-* > >installed in > >/home/masahiro/tools/aarch64-linaro-7.5/bin > > > > > > > >Basically, there are two ways to use it. > > > >[1] > >PATH=$PATH:/home/masahiro/tools/aarch64-linaro-7.5/bin > >CROSS_COMPILE=aarch64-linux-gnu- > > > > > >[2] > >Without setting PATH, > >CROSS_COMPILE=~/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu- > > > > > > > >I usually do [2] (and so does intel's 0day bot). > > > > > > > >This patch works for the use-case [1] > >but if I do [2], --prefix is set to a strange path: > > > >--prefix=/home/masahiro/tools/aarch64-linaro-7.5/bin//home/masahiro/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu- > > Thanks. I did not know the use-case [2]. > This explains why there is a `$(notdir ...)` in > `CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%))` > > > > > > > >Interestingly, the build is still successful. > >Presumably Clang searches for more paths > >when $(prefix)$needle is not found ? > > The priority order is: > > -B(--prefix), COMPILER_PATH, detected gcc-cross paths > > (In GCC, -B paths get prepended to the COMPILER_PATH list. Clang<=11 incorrectly > adds -B to the COMPILER_PATH list. I have fixed it for 12.0.0) > > If -B fails, the detected gcc-cross paths may still be able to find > /usr/bin/aarch64-linux-gnu- > > For example, on my machine (a variant of Debian testing), Clang finds > $(realpath > /usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/as), > which is /usr/bin/aarch64-linux-gnu-as > > > > >I applied your patch and added -v option > >to see which assembler was internally invoked: > > > > "/home/masahiro/tools/aarch64-linaro-7.5/lib/gcc/aarch64-linux-gnu/7.5.0/../../../../aarch64-linux-gnu/bin/as" > >-EL -I ./arch/arm64/include -I ./arch/arm64/include/generated -I > >./include -I ./arch/arm64/include/uapi -I > >./arch/arm64/include/generated/uapi -I ./include/uapi -I > >./include/generated/uapi -o kernel/smp.o /tmp/smp-2ec2c7.s > > > > > >Ok, it looks like Clang found an alternative path > >to the correct 'as'. > > > > > > > > > >But, to keep the original behavior for both [1] and [2], > >how about this? > > > >CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) > > > > > > > >Then, I can get this: > > > > "/home/masahiro/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu-as" > >-EL -I ./arch/arm64/include -I ./arch/arm64/include/generated -I > >./include -I ./arch/arm64/include/uapi -I > >./arch/arm64/include/generated/uapi -I ./include/uapi -I > >./include/generated/uapi -o kernel/smp.o /tmp/smp-16d76f.s > > This looks good. > > Agreed that `--prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))` should work for both [1] and [2]. > > Shall I send a v4? Or you are kind enough that you'll just add your Signed-off-by: tag > and fix that for me? :) > I fixed it up and applied to linux-kbuild/fixes. Thanks. While I am here, could you teach me a bit more? The top Makefile sets the following option as well: CLANG_GCC_TC := --gcc-toolchain=$(GCC_TOOLCHAIN) I checked the manual: https://clang.llvm.org/docs/ClangCommandLineReference.html -B, --prefix , --prefix= Add to search path for binaries and object files used implicitly --gcc-toolchain=, -gcc-toolchain Use the gcc toolchain at the given directory It is not clear to me how they work differently when clang searches for toolchains. If I delete --gcc-toolchain from the top Makefile, clang fails to link standalone programs because it wrongly invokes /usr/bin/ld instead of aarch64-linux-gnu-ld. Does Clang search for gnu assembler based on --prefix option? And, searches for a linker based on --gcc-toolchain ? -- Best Regards Masahiro Yamada