Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1629636pxb; Thu, 4 Mar 2021 16:56:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJzAM+9cge3msCEjYHF8u11M1mmK12A2ty5kxZ44ghmtVOKDI6elpGZmxyjEP59N/4/QG+28 X-Received: by 2002:a05:6638:3ba:: with SMTP id z26mr7225153jap.40.1614905804870; Thu, 04 Mar 2021 16:56:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614905804; cv=none; d=google.com; s=arc-20160816; b=npMWN061LikIr3ZTwwGQ4ijsc2nNO/CGdsjqUrVnDeEQdzPfsNNka+WB1CAsVX0foj MI7cvUPycUdNZHdEHPTEBpMMBkXdiAUg8Q5jNS+uZNHRr5foeb9d+NgfDXBIkZ6Pb1GT ZYDxBAG/s9m/acs8qhqSO2nlAL7p9bj/o+ftboW5qJp9lHg8hXZ69+Ju1oAj09iSxOkC Tp1yNMhooKEt5prZLfi4iYt39nrU82XD90aH6gPY3+dNbLW3UJmqI9pDgWbLE+fWyfdd S4pMg8FV45eJrvkmT1ycSoIO9/zQmxIhxxNjelZca4bAFwHXXJeSG4DT4tziXg0A6PVd gp8w== 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=55l/p5w7xRBRzeE5LFWuLvvcDqxofKt6XTrgAWZQcus=; b=oJVOcvOJbduFLtiThxTKo1DcGxhepmQPrD4ekuaiN4QvPghf26yBjIh17n2klLKd2O 9g/gSExRiKeEqBaA5BY21/QRP1zbCdtQ38+g8Jdo5mBIrLQNsCmX2qw34LfClWK/EPEi 9uQUbnLmYt4xIOXt20cBpslei14IvcRcL+9fy/4Njf2bnU9AUBLtNbrx+h9xZgxHkoCU +y7lWPenWmhS8KfKEIHC+fFyb/qtACscKs2+wVw4wHRHML00hAn+vEgG6KdteDd7jNVA gJ7oHVS/YIYvicA4dV617xvJkrt9GFJqB1EUOPXvggfDU6iEoSGw6cai+/IUoB30LGH/ VljQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IilvZn5V; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si678145ilv.48.2021.03.04.16.56.31; Thu, 04 Mar 2021 16:56:44 -0800 (PST) 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=@google.com header.s=20161025 header.b=IilvZn5V; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232450AbhCDTMT (ORCPT + 99 others); Thu, 4 Mar 2021 14:12:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230505AbhCDTLz (ORCPT ); Thu, 4 Mar 2021 14:11:55 -0500 Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 608E6C061761 for ; Thu, 4 Mar 2021 11:11:15 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id z5so3848387plg.3 for ; Thu, 04 Mar 2021 11:11:15 -0800 (PST) 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=55l/p5w7xRBRzeE5LFWuLvvcDqxofKt6XTrgAWZQcus=; b=IilvZn5VSKOXpIHzzLZvKEuln8wWilduJnGjegs0g3RarCpl8F7UbpX1kZqY7bczML G3RAhQQnQSyJMgEbFDOpbGxnIcmyH3AQC0K6rJXuh5nZmMkod/dNm2KsIlqgIlfLvHVf VB6grb+6yQSQ02V+CUXakJL/jeeN5q+264PiQaEm3gbogALQoMqyilRm0aErdE4ko9mr wC8wgrAGSfehRiwplRrKFAoqZRFHkVB5qeYgSf6AdEvvkwjO+k9oFrAbkyF8KB1H3chH t2LL6qBXMdWZMEvEtRzTkSDGKBv5kCDsosIALhuffuV418ZssCqW/3kuiXOuHk+SUEIz WEKg== 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=55l/p5w7xRBRzeE5LFWuLvvcDqxofKt6XTrgAWZQcus=; b=e0Hsz9iX7jkM+YCWDG5UFY3OXPS/8gx80/77ZRuWPnDmtncPatzMGgwUeJuZ5uQyC5 WWqtL9qjou9ttUZj4N9uU00d64naM/Zc+gOcfjLFO40c8CdMWH/tjzT+FZdUKnSwaFDF CtSwImQLPI6XRBRlfi03ERx8QN+sTz71nAmp8hiFB0m53tWM6ZcF73dVNrEaXH32LqUV XWJFuKrW5cRdzlv4Sz8iVbR/I6SpruxK+VB7otqdWXlUPQ+sViXNark+4Uo4hsnGB7KK RkzF7+ZXrPqXcReCT15mhEzHkGDEeht20JpWI4qxX57zEtpe3awJe3taDIt8x5L5Am+R GzhQ== X-Gm-Message-State: AOAM530QIq0Uidqpr458ik4wfIUl7EEG1z7uN5q6Rc1MlRkxFc3yZqz6 wf+AcW1Zb0fkI/1HGMAFOG8MBUBsZSPOxCPDaTM02w== X-Received: by 2002:a17:90b:3550:: with SMTP id lt16mr5870688pjb.47.1614885074754; Thu, 04 Mar 2021 11:11:14 -0800 (PST) MIME-Version: 1.0 References: <20210303230708.l6pbk5o5nc2qa5of@google.com> In-Reply-To: <20210303230708.l6pbk5o5nc2qa5of@google.com> From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Thu, 4 Mar 2021 11:11:03 -0800 Message-ID: Subject: Re: [PATCH 1/2] Makefile: Remove '--gcc-toolchain' flag To: Masahiro Yamada Cc: Nathan Chancellor , Michal Marek , Nick Desaulniers , Linux Kbuild mailing list , Linux Kernel Mailing List , clang-built-linux Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 3, 2021 at 3:07 PM Fangrui Song wrote: > > > On 2021-03-03, Masahiro Yamada wrote: > >Hi. > > > >On Wed, Mar 3, 2021 at 6:44 AM Fangrui Song wrote: > >> > >> Reviewed-by: Fangrui Song > >> > >> Thanks for the clean-up! > >> --gcc-toolchain= is an obsscure way searching for GCC installation prefixes (--prefix). > >> The logic is complex and different for different distributions/architectures. > >> > >> If we specify --prefix= (-B) explicitly, --gcc-toolchain is not needed. > > > > > >I tested this, and worked for me too. > > > >Before applying this patch, could you please > >help me understand the logic? > > > > > > > > > >I checked the manual > >(https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-b-dir) > > > > > > > >-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 > > > > > >Hmm, this description is too concise > >to understand how it works... > > > > > > > >I use Ubuntu 20.10. > > > >I use distro's default clang > >located in /usr/bin/clang. > > > >I place my aarch64 linaro toolchain in > >/home/masahiro/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu-gcc, > >which is not in my PATH environment. > > > > > > > > > >From my some experiments, > > > >clang --target=aarch64-linux-gnu -no-integrated-as \ > >--prefix=/home/masahiro/tools/aarch64-linaro-7.5/bin/aarch64-linux-gnu- ... > > > >works almost equivalent to > > > >PATH=/home/masahiro/tools/aarch64-linaro-7.5/bin:$PATH \ > >clang --target=aarch64-linux-gnu -no-integrated-as ... > > > > > >Then, clang will pick up aarch64-linux-gnu-as > >found in the search path. > > > >Is this correct? > > > > > >On the other hand, I could not understand > >what the purpose of --gcc-toolchain= is. > > > > > >Even if I add --gcc-toolchain=/home/masahiro/tools/aarch64-linaro-7.5, > >it does not make any difference, and it is completely useless. > > > > > >I read the comment from stephenhines: > >https://github.com/ClangBuiltLinux/linux/issues/78 > > > >How could --gcc-toolchain be used > >in a useful way? > > --gcc-toolchain was introduced in > https://reviews.llvm.org/rG1af7c219c7113a35415651127f05cdf056b63110 > to provide a flexible alternative to autoconf configure-time --with-gcc-toolchain (now cmake variable GCC_INSTALL_PREFIX). > > I agree the option is confusing, the documentation is poor, and probably very few people understand what it does. > I apologize that my previous reply is not particular correct. > So the more correct answer is below: > > > A --prefix option can specify either of > > 1) A directory (for something like /a/b/lib/gcc/arm-linux-androideabi, this should be /a/b, the parent directory of 'lib') > 2) A path fragment like /usr/bin/aarch64-linux-gnu- > > The directory values of the --prefix list and --gcc-toolchain are used to detect GCC installation directories. The directory is used to fetch include directories, system library directories and binutils directories (as, objcopy). > (See below, Linux kernel only needs the binutils executables, so the include/library logic is really useless to us) > > The logic is around https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Gnu.cpp#L1910 > > Prefixes = --prefix/-B list (only the directory subset is effective) > StringRef GCCToolchainDir = --gcc-toolchain= or CMake variable GCC_INSTALL_PREFIX > if (GCCToolchainDir != "") { > Prefixes.push_back(std::string(GCCToolchainDir)); > } else { > if (!D.SysRoot.empty()) { > Prefixes.push_back(D.SysRoot); > // Add D.SysRoot+"/usr" to Prefixes. Some distributions add more directories. > AddDefaultGCCPrefixes(TargetTriple, Prefixes, D.SysRoot); > } > > // D.InstalledDir is the directory of the clang executable, e.g. /usr/bin > Prefixes.push_back(D.InstalledDir + "/.."); > > if (D.SysRoot.empty()) > AddDefaultGCCPrefixes(TargetTriple, Prefixes, D.SysRoot); > } > > // Gentoo / ChromeOS specific logic. > // I think this block is misplaced. > if (GCCToolchainDir == "" || GCCToolchainDir == D.SysRoot + "/usr") { > ... > } > > // Loop over the various components which exist and select the best GCC > // installation available. GCC installs are ranked by version number. > Version = GCCVersion::Parse("0.0.0"); > for (const std::string &Prefix : Prefixes) { > auto &VFS = D.getVFS(); > if (!VFS.exists(Prefix)) > continue; > > // CandidateLibDirs is a subset of {/lib64, /lib32, /lib}. > for (StringRef Suffix : CandidateLibDirs) { > const std::string LibDir = Prefix + Suffix.str(); > if (!VFS.exists(LibDir)) > continue; > bool GCCDirExists = VFS.exists(LibDir + "/gcc"); > bool GCCCrossDirExists = VFS.exists(LibDir + "/gcc-cross"); > > // Precise match. Detect $Prefix/lib/$--target > ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, TargetTriple.str(), > false, GCCDirExists, GCCCrossDirExists); > // Usually empty. > for (StringRef Candidate : ExtraTripleAliases) // Try these first. > ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, Candidate, false, > GCCDirExists, GCCCrossDirExists); > // CandidateTripleAliases is a set with "x86_64-linux-gnu", "x86_64-unknown-linux-gnu", ... > // This loop detects directories like $Prefix/lib/x86_64-linux-gnu. > for (StringRef Candidate : CandidateTripleAliases) > ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, Candidate, false, > GCCDirExists, GCCCrossDirExists); > } > for (StringRef Suffix : CandidateBiarchLibDirs) { > const std::string LibDir = Prefix + Suffix.str(); > if (!VFS.exists(LibDir)) > continue; > bool GCCDirExists = VFS.exists(LibDir + "/gcc"); > bool GCCCrossDirExists = VFS.exists(LibDir + "/gcc-cross"); > for (StringRef Candidate : CandidateBiarchTripleAliases) > ScanLibDirForGCCTriple(TargetTriple, Args, LibDir, Candidate, true, > GCCDirExists, GCCCrossDirExists); > } > } > > > The comment > // Loop over the various components which exist and select the best GCC > // installation available. GCC installs are ranked by version number. > > is important. If you specify --prefix=$dir but not --gcc-toolchain, > the system cross toolchains (/usr/lib/gcc-cross) are also candidates and they may win. > > Specifying just --gcc-toolchain (due to if (GCCToolchainDir != "")) can effectively ignore system cross toolchains. > > > > In the Linux kernel use case, We specify -nostdinc and -nostdlib so GCC include/library directories are not used. > We seem to prefer the non-directory use of --prefix: CROSS_COMPILE=arm-linux-gnueabi- > So all the directory detection logic can be dropped. > > > A better commit message is along the lines of: > --gcc-toolchain specified directory is used to detect GCC installations > for include/library directories and binutils executables. > > We already specify something like --prefix=aarch64-linux-gnu- to inform > Clang of the binutils executables, and we do not need include/library > directories, so we can drop --gcc-toolchain. > > > > > > > > > > > > > > > >> On 2021-03-02, Nathan Chancellor wrote: > >> >This is not necessary anymore now that we specify '--prefix=', which > >> >tells clang exactly where to find the GNU cross tools. This has been > >> >verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as well as a > >> >distribution version of LLVM 11.1.0 without binutils in the LLVM > >> >toolchain locations. > >> > > >> >Signed-off-by: Nathan Chancellor > >> >--- > >> > Makefile | 4 ---- > >> > 1 file changed, 4 deletions(-) > >> > > >> >diff --git a/Makefile b/Makefile > >> >index f9b54da2fca0..c20f0ad8be73 100644 > >> >--- a/Makefile > >> >+++ b/Makefile > >> >@@ -568,10 +568,6 @@ ifneq ($(CROSS_COMPILE),) > >> > CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > >> > GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) > >> > 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) > >> > endif > >> > ifneq ($(LLVM_IAS),1) > >> > CLANG_FLAGS += -no-integrated-as > >> > > >> >base-commit: 7a7fd0de4a9804299793e564a555a49c1fc924cb > >> >-- > >> >2.31.0.rc0.75.gec125d1bc1 > >> > > >> >-- > >> >You received this message because you are subscribed to the Google Groups "Clang Built Linux" group. > >> >To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com. > >> >To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/20210302210646.3044738-1-nathan%40kernel.org. > > > > > > > >-- > >Best Regards > > > >Masahiro Yamada I've sent https://reviews.llvm.org/D97902 to improve the -B and --gcc-toolchain documentation, and posted https://lists.llvm.org/pipermail/cfe-dev/2021-March/067820.html (Message-Id: CAFP8O3JZBWx6OYm14KhP0f+RNU_OHLPLZnyX7jDtCL_yvnJDfA@mail.gmail.com) to discuss Clang's current weird behaviors. * --gcc-toolchain suppresses GCC detection under sysroot, -B doesn't. I'd like that -B suppresses GCC detection under sysroot as well but unsure whether some folks are dependent on this behavior. * With -B -B -B --gcc-toolchain, the largest version instead of the first wins. I think it makes sense to select the first option where a GCC installation is found. Hey, this list has a lot developers using cross compilers. Do you have thoughts to share? :)