[PATCH v3 0/2] infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[PATCH v3 0/2] infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Nick Desaulniers]

We get constant feedback that the command line invocation of make is too
long. CROSS_COMPILE is helpful when a toolchain has a prefix of the
target triple, or is an absolute path outside of $PATH, but it's mostly
redundant for a given ARCH.

Instead, let's infer it from SRCARCH, and move some flag handling into a
new file included from the top level Makefile.

Changes v2 -> v3:
* Remove requirement that LLVM=1 be set. Instead, if building with just
  CC=clang LLVM_IAS=1 instead of LLVM=1 LLVM_IAS=1, you should use
  LD=ld.lld explicitly, or LD=aarch64-linux-gnu-ld. (As per Masahiro)
  Example:

  $ ARCH=arm64 make CC=clang LLVM_IAS=1 LD=ld.lld OBJCOPY=llvm-objcopy \
    STRIP=llvm-strip -j72 defconfig all

  (It's still preferable to use LLVM=1 IMO, but this is maximally
  flexible.)
* Change oneliner from LLVM=1 to CC=clang.
* Update Docs slightly.

Changes v1 -> v2:
* patch 1/2 untouched.
* Fix typos in commit message as per Geert and Masahiro.
* Use SRCARCH instead of ARCH, simplifying x86 handling, as per
  Masahiro. Add his sugguested by tag.
* change commit oneline from 'drop' to 'infer.'
* Add detail about explicit host --target and relationship of ARCH to
  SRCARCH, as per Masahiro.

Nick Desaulniers (2):
  Makefile: move initial clang flag handling into scripts/Makefile.clang
  Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

 Documentation/kbuild/llvm.rst |  6 +++++
 MAINTAINERS                   |  1 +
 Makefile                      | 15 +------------
 scripts/Makefile.clang        | 42 +++++++++++++++++++++++++++++++++++
 4 files changed, 50 insertions(+), 14 deletions(-)
 create mode 100644 scripts/Makefile.clang


base-commit: 27932b6a2088eac7a5afa5471963b926cfbb4de7
-- 
2.32.0.432.gabb21c7263-goog

[PATCH v3 1/2] Makefile: move initial clang flag handling into scripts/Makefile.clang

[Nick Desaulniers]

With some of the changes we'd like to make to CROSS_COMPILE, the initial
block of clang flag handling which controls things like the target triple,
whether or not to use the integrated assembler and how to find GAS,
and erroring on unknown warnings is becoming unwieldy. Move it into its
own file under scripts/.

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Changes V2 -> V3:
* Pick up Nathan's RB tag.

 MAINTAINERS            |  1 +
 Makefile               | 15 +--------------
 scripts/Makefile.clang | 14 ++++++++++++++
 3 files changed, 16 insertions(+), 14 deletions(-)
 create mode 100644 scripts/Makefile.clang

diff --git a/MAINTAINERS b/MAINTAINERS
index 81e1edeceae4..9c1205c258c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4433,6 +4433,7 @@ B:	https://github.com/ClangBuiltLinux/linux/issues
 C:	irc://chat.freenode.net/clangbuiltlinux
 F:	Documentation/kbuild/llvm.rst
 F:	include/linux/compiler-clang.h
+F:	scripts/Makefile.clang
 F:	scripts/clang-tools/
 K:	\b(?i:clang|llvm)\b
 
diff --git a/Makefile b/Makefile
index cbab0dc53065..010e3a4e770b 100644
--- a/Makefile
+++ b/Makefile
@@ -586,20 +586,7 @@ endif
 CC_VERSION_TEXT = $(subst $(pound),,$(shell $(CC) --version 2>/dev/null | head -n 1))
 
 ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
-ifneq ($(CROSS_COMPILE),)
-CLANG_FLAGS	+= --target=$(notdir $(CROSS_COMPILE:%-=%))
-endif
-ifeq ($(LLVM_IAS),1)
-CLANG_FLAGS	+= -integrated-as
-else
-CLANG_FLAGS	+= -no-integrated-as
-GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
-CLANG_FLAGS	+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
-endif
-CLANG_FLAGS	+= -Werror=unknown-warning-option
-KBUILD_CFLAGS	+= $(CLANG_FLAGS)
-KBUILD_AFLAGS	+= $(CLANG_FLAGS)
-export CLANG_FLAGS
+include $(srctree)/scripts/Makefile.clang
 endif
 
 # Include this also for config targets because some architectures need
diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
new file mode 100644
index 000000000000..297932e973d4
--- /dev/null
+++ b/scripts/Makefile.clang
@@ -0,0 +1,14 @@
+ifneq ($(CROSS_COMPILE),)
+CLANG_FLAGS	+= --target=$(notdir $(CROSS_COMPILE:%-=%))
+endif
+ifeq ($(LLVM_IAS),1)
+CLANG_FLAGS	+= -integrated-as
+else
+CLANG_FLAGS	+= -no-integrated-as
+GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit))
+CLANG_FLAGS	+= --prefix=$(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE))
+endif
+CLANG_FLAGS	+= -Werror=unknown-warning-option
+KBUILD_CFLAGS	+= $(CLANG_FLAGS)
+KBUILD_AFLAGS	+= $(CLANG_FLAGS)
+export CLANG_FLAGS
-- 
2.32.0.432.gabb21c7263-goog

[PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Nick Desaulniers]

We get constant feedback that the command line invocation of make is too
long. CROSS_COMPILE is helpful when a toolchain has a prefix of the
target triple, or is an absolute path outside of $PATH, but it's mostly
redundant for a given SRCARCH. SRCARCH itself is derived from ARCH
(normalized for a few different targets).

If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
KBUILD_CFLAGS, and KBUILD_AFLAGS based on $SRCARCH.

Previously, we'd cross compile via:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1
Now:
$ ARCH=arm64 make LLVM=1 LLVM_IAS=1

For native builds (not involving cross compilation) we now explicitly
specify a target triple rather than rely on the implicit host triple.

Link: https://github.com/ClangBuiltLinux/linux/issues/1399
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Changes v2 -> v3:
* Drop check/requirement for LLVM=1, as per Masahiro.
* Change oneliner from LLVM=1 LLVM_IAS=1 to CC=clang LLVM_IAS=1.
* Don't carry forward Nathan's RB/TB tags. :( Sorry Nathan, but thank
  you for testing+reviewing v2.
* Update wording of docs slightly.

Changes v1 -> v2:
* Fix typos in commit message as per Geert and Masahiro.
* Use SRCARCH instead of ARCH, simplifying x86 handling, as per
  Masahiro. Add his sugguested by tag.
* change commit oneline from 'drop' to 'infer.'
* Add detail about explicit host --target and relationship of ARCH to
  SRCARCH, as per Masahiro.

Changes RFC -> v1:
* Rebase onto linux-kbuild/for-next
* Keep full target triples since missing the gnueabi suffix messes up
  32b ARM. Drop Fangrui's sugguested by tag. Update commit message to
  drop references to arm64.
* Flush out TODOS.
* Add note about -EL/-EB, -m32/-m64.
* Add note to Documentation/.

 Documentation/kbuild/llvm.rst |  6 ++++++
 scripts/Makefile.clang        | 32 ++++++++++++++++++++++++++++++--
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index b18401d2ba82..aef1587fc09b 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -46,6 +46,12 @@ example: ::
 
 	clang --target=aarch64-linux-gnu foo.c
 
+When both ``CC=clang`` (set via ``LLVM=1``) and ``LLVM_IAS=1`` are used,
+``CROSS_COMPILE`` becomes unnecessary and can be inferred from ``ARCH``.
+Example: ::
+
+	ARCH=arm64 make LLVM=1 LLVM_IAS=1
+
 LLVM Utilities
 --------------
 
diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
index 297932e973d4..a1b46811bdc6 100644
--- a/scripts/Makefile.clang
+++ b/scripts/Makefile.clang
@@ -1,6 +1,34 @@
-ifneq ($(CROSS_COMPILE),)
+# Individual arch/{arch}/Makfiles should use -EL/-EB to set intended endianness
+# and -m32/-m64 to set word size based on Kconfigs instead of relying on the
+# target triple.
+ifeq ($(CROSS_COMPILE),)
+ifeq ($(LLVM_IAS),1)
+ifeq ($(SRCARCH),arm)
+CLANG_FLAGS	+= --target=arm-linux-gnueabi
+else ifeq ($(SRCARCH),arm64)
+CLANG_FLAGS	+= --target=aarch64-linux-gnu
+else ifeq ($(SRCARCH),hexagon)
+CLANG_FLAGS	+= --target=hexagon-linux-gnu
+else ifeq ($(SRCARCH),m68k)
+CLANG_FLAGS	+= --target=m68k-linux-gnu
+else ifeq ($(SRCARCH),mips)
+CLANG_FLAGS	+= --target=mipsel-linux-gnu
+else ifeq ($(SRCARCH),powerpc)
+CLANG_FLAGS	+= --target=powerpc64le-linux-gnu
+else ifeq ($(SRCARCH),riscv)
+CLANG_FLAGS	+= --target=riscv64-linux-gnu
+else ifeq ($(SRCARCH),s390)
+CLANG_FLAGS	+= --target=s390x-linux-gnu
+else ifeq ($(SRCARCH),x86)
+CLANG_FLAGS	+= --target=x86_64-linux-gnu
+else
+$(error Specify CROSS_COMPILE or add '--target=' option to scripts/Makefile.clang)
+endif # SRCARCH
+endif # LLVM_IAS
+else
 CLANG_FLAGS	+= --target=$(notdir $(CROSS_COMPILE:%-=%))
-endif
+endif # CROSS_COMPILE
+
 ifeq ($(LLVM_IAS),1)
 CLANG_FLAGS	+= -integrated-as
 else
-- 
2.32.0.432.gabb21c7263-goog

Re: [PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Arnd Bergmann]

On Thu, Jul 29, 2021 at 6:50 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> We get constant feedback that the command line invocation of make is too
> long. CROSS_COMPILE is helpful when a toolchain has a prefix of the
> target triple, or is an absolute path outside of $PATH, but it's mostly
> redundant for a given SRCARCH. SRCARCH itself is derived from ARCH
> (normalized for a few different targets).
>
> If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> KBUILD_CFLAGS, and KBUILD_AFLAGS based on $SRCARCH.
>
> Previously, we'd cross compile via:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1
> Now:
> $ ARCH=arm64 make LLVM=1 LLVM_IAS=1
>
> For native builds (not involving cross compilation) we now explicitly
> specify a target triple rather than rely on the implicit host triple.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1399
> Suggested-by: Arnd Bergmann <arnd@kernel.org>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Looks good to me,

Acked-by: Arnd Bergmann <arnd@arndb.de>

> +else
> +$(error Specify CROSS_COMPILE or add '--target=' option to scripts/Makefile.clang)
> +endif # SRCARCH
> +endif # LLVM_IAS

Now in theory I suppose we could just have the fallback use
--target="$(SRCARCH)-linux-gnu"
to avoid having to change this for every new architecture. I think in
most cases, this
would just work, even though a lot of the one you listed have
different patterns.

       Arnd

Re: [PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Nathan Chancellor]

I realized that the title of this commit is not really right. We are not 
inferring CROSS_COMPILE, we are inferring '--target='.

On 7/29/2021 9:50 AM, Nick Desaulniers wrote:
> We get constant feedback that the command line invocation of make is too
> long. CROSS_COMPILE is helpful when a toolchain has a prefix of the
> target triple, or is an absolute path outside of $PATH, but it's mostly
> redundant for a given SRCARCH. SRCARCH itself is derived from ARCH

I feel like the beginning of this needs a little work.

1. "...invocation of make is too long when compiling with LLVM" would be 
a little more accurate.

2. "it's mostly redundant for a given SRCARCH" is not quite true in my 
eyes. For example, you could have aarch64-linux-, aarch64-elf-, or 
aarch64-linux-gnu-, and to my knowledge, all of these can compile a 
working Linux kernel. Again, saying "with LLVM", even mentioning its 
multitargeted nature, might make it a little more accurate to the casual 
passerby.

> (normalized for a few different targets).
> 
> If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> KBUILD_CFLAGS, and KBUILD_AFLAGS based on $SRCARCH.
> 
> Previously, we'd cross compile via:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1
> Now:
> $ ARCH=arm64 make LLVM=1 LLVM_IAS=1
> 
> For native builds (not involving cross compilation) we now explicitly
> specify a target triple rather than rely on the implicit host triple.
> 
> Link: https://github.com/ClangBuiltLinux/linux/issues/1399
> Suggested-by: Arnd Bergmann <arnd@kernel.org>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>

Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>

> ---
> Changes v2 -> v3:
> * Drop check/requirement for LLVM=1, as per Masahiro.
> * Change oneliner from LLVM=1 LLVM_IAS=1 to CC=clang LLVM_IAS=1.
> * Don't carry forward Nathan's RB/TB tags. :( Sorry Nathan, but thank
>    you for testing+reviewing v2.
> * Update wording of docs slightly.
> 
> Changes v1 -> v2:
> * Fix typos in commit message as per Geert and Masahiro.
> * Use SRCARCH instead of ARCH, simplifying x86 handling, as per
>    Masahiro. Add his sugguested by tag.
> * change commit oneline from 'drop' to 'infer.'
> * Add detail about explicit host --target and relationship of ARCH to
>    SRCARCH, as per Masahiro.
> 
> Changes RFC -> v1:
> * Rebase onto linux-kbuild/for-next
> * Keep full target triples since missing the gnueabi suffix messes up
>    32b ARM. Drop Fangrui's sugguested by tag. Update commit message to
>    drop references to arm64.
> * Flush out TODOS.
> * Add note about -EL/-EB, -m32/-m64.
> * Add note to Documentation/.
> 
>   Documentation/kbuild/llvm.rst |  6 ++++++
>   scripts/Makefile.clang        | 32 ++++++++++++++++++++++++++++++--
>   2 files changed, 36 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
> index b18401d2ba82..aef1587fc09b 100644
> --- a/Documentation/kbuild/llvm.rst
> +++ b/Documentation/kbuild/llvm.rst
> @@ -46,6 +46,12 @@ example: ::
>   
>   	clang --target=aarch64-linux-gnu foo.c
>   
> +When both ``CC=clang`` (set via ``LLVM=1``) and ``LLVM_IAS=1`` are used,
> +``CROSS_COMPILE`` becomes unnecessary and can be inferred from ``ARCH``.

I am not a fan of this sentence because it implies that something like 
'make ARCH=arm64 CC=clang LLVM_IAS=1' will work fine, which is not true. 
We still need CROSS_COMPILE for binutils in this configuration.

CROSS_COMPILE provides the value for '--target=' and the prefix for the 
GNU tools such as ld, objcopy, and readelf. I think this direction is a 
regression because we are just talking about the first use of 
CROSS_COMPILE rather than the second at the same time.

With LLVM=1 LLVM_IAS=1, we KNOW that the user will be using all LLVM 
tools. Sure, they are free to override LD, OBJCOPY, READELF, etc with 
the GNU variants but they have to provide the prefix because LLVM=1 
overrides the $(CROSS_COMPILE)<tool> assignments so it is irrelevant to 
us. As Masahiro mentioned, the user is free to individually specify all 
the tools by their individual variables such as LD=ld.lld BUT at that 
point, the user should be aware of what they are doing and specify 
CROSS_COMPILE.

While I understand that the LLVM=1 LLVM_IAS=1 case works perfectly fine 
with this series, I am of the belief that making it work for CC=clang 
LLVM_IAS=1 is a mistake because there is no way for that configuration 
to work for cross compiling without CROSS_COMPILE.

At the same time, not a hill I am willing to die on, hence the tags above.

> +Example: ::
> +
> +	ARCH=arm64 make LLVM=1 LLVM_IAS=1
> +
>   LLVM Utilities
>   --------------
>   
> diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
> index 297932e973d4..a1b46811bdc6 100644
> --- a/scripts/Makefile.clang
> +++ b/scripts/Makefile.clang
> @@ -1,6 +1,34 @@
> -ifneq ($(CROSS_COMPILE),)
> +# Individual arch/{arch}/Makfiles should use -EL/-EB to set intended endianness

Makefiles

> +# and -m32/-m64 to set word size based on Kconfigs instead of relying on the
> +# target triple.
> +ifeq ($(CROSS_COMPILE),)
> +ifeq ($(LLVM_IAS),1)
> +ifeq ($(SRCARCH),arm)
> +CLANG_FLAGS	+= --target=arm-linux-gnueabi
> +else ifeq ($(SRCARCH),arm64)
> +CLANG_FLAGS	+= --target=aarch64-linux-gnu
> +else ifeq ($(SRCARCH),hexagon)
> +CLANG_FLAGS	+= --target=hexagon-linux-gnu
> +else ifeq ($(SRCARCH),m68k)
> +CLANG_FLAGS	+= --target=m68k-linux-gnu
> +else ifeq ($(SRCARCH),mips)
> +CLANG_FLAGS	+= --target=mipsel-linux-gnu
> +else ifeq ($(SRCARCH),powerpc)
> +CLANG_FLAGS	+= --target=powerpc64le-linux-gnu
> +else ifeq ($(SRCARCH),riscv)
> +CLANG_FLAGS	+= --target=riscv64-linux-gnu
> +else ifeq ($(SRCARCH),s390)
> +CLANG_FLAGS	+= --target=s390x-linux-gnu
> +else ifeq ($(SRCARCH),x86)
> +CLANG_FLAGS	+= --target=x86_64-linux-gnu
> +else
> +$(error Specify CROSS_COMPILE or add '--target=' option to scripts/Makefile.clang)
> +endif # SRCARCH
> +endif # LLVM_IAS
> +else
>   CLANG_FLAGS	+= --target=$(notdir $(CROSS_COMPILE:%-=%))
> -endif
> +endif # CROSS_COMPILE
> +
>   ifeq ($(LLVM_IAS),1)
>   CLANG_FLAGS	+= -integrated-as
>   else
> 

Re: [PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Nick Desaulniers]

On Thu, Jul 29, 2021 at 2:00 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> While I understand that the LLVM=1 LLVM_IAS=1 case works perfectly fine
> with this series, I am of the belief that making it work for CC=clang
> LLVM_IAS=1 is a mistake because there is no way for that configuration
> to work for cross compiling without CROSS_COMPILE.

So with v3 of this change, rather than:

$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j72

If you wanted to omit CROSS_COMPILE, you'd need:

$ ARCH=arm64 make CC=clang LLVM_IAS=1 LD=ld.lld OBJCOPY=llvm-objcopy
STRIP=llvm-strip

or

$ ARCH=arm64 make CC=clang LLVM_IAS=1 LD=aarch64-linux-gnu-ld
OBJCOPY=aarch64-linux-gnu-objcopy STRIP=aarch64-linux-gnu-strip

That's straight up worse IMO and defeats the purpose of "shortening
the command line," which should be the goal.  Not "making CC=clang
maximally flexible."  We don't want folks generally using CC=clang;
preferably they'd use LLVM=1.  I need to rewrite our docs to make that
more explicit and straightforward.  And if folks would prefer to use
CC=clang for whatever reason, let them explicitly state CROSS_COMPILE
then.

So I agree with Nathan, and hope Masahiro will reconsider that perhaps
the v2 variant that required LLVM=1 maybe makes more sense.

Either way, I need to fix the comment in the new script, commit
message, and docs, so v4 is necessary.

I'm tempted to add a rewrite of our docs to say "just use LLVM=1"
front and center, then get into finer grain details below, moving this
second patch to be the third in a series.  Let's see what Masahiro's
thoughts are though first. (I do appreciate them, even when I
disagree).
-- 
Thanks,
~Nick Desaulniers

Re: [PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Miguel Ojeda]

On Fri, Jul 30, 2021 at 2:19 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> maximally flexible."  We don't want folks generally using CC=clang;
> preferably they'd use LLVM=1.  I need to rewrite our docs to make that
> more explicit and straightforward.  And if folks would prefer to use
> CC=clang for whatever reason, let them explicitly state CROSS_COMPILE
> then.

Perhaps it would be nice to clarify the "level of support" for
`CC=clang` too, in particular long-term when `LLVM=1` works for all
architectures.

In other words, is `CC=clang` going to remain supported/maintained, or
it will be something that will still compile/boot but not expected to
be used by anyone in production, or dropped altogether (not the `CC`
option itself, of course, I refer to the mix of toolchains)?

Thanks,

Cheers,
Miguel

Re: [PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Masahiro Yamada]

On Fri, Jul 30, 2021 at 6:00 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> I realized that the title of this commit is not really right. We are not
> inferring CROSS_COMPILE, we are inferring '--target='.
>
> On 7/29/2021 9:50 AM, Nick Desaulniers wrote:
> > We get constant feedback that the command line invocation of make is too
> > long. CROSS_COMPILE is helpful when a toolchain has a prefix of the
> > target triple, or is an absolute path outside of $PATH, but it's mostly
> > redundant for a given SRCARCH. SRCARCH itself is derived from ARCH
>
> I feel like the beginning of this needs a little work.
>
> 1. "...invocation of make is too long when compiling with LLVM" would be
> a little more accurate.
>
> 2. "it's mostly redundant for a given SRCARCH" is not quite true in my
> eyes. For example, you could have aarch64-linux-, aarch64-elf-, or
> aarch64-linux-gnu-, and to my knowledge, all of these can compile a
> working Linux kernel. Again, saying "with LLVM", even mentioning its
> multitargeted nature, might make it a little more accurate to the casual
> passerby.
>
> > (normalized for a few different targets).
> >
> > If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> > KBUILD_CFLAGS, and KBUILD_AFLAGS based on $SRCARCH.
> >
> > Previously, we'd cross compile via:
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1
> > Now:
> > $ ARCH=arm64 make LLVM=1 LLVM_IAS=1
> >
> > For native builds (not involving cross compilation) we now explicitly
> > specify a target triple rather than rely on the implicit host triple.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1399
> > Suggested-by: Arnd Bergmann <arnd@kernel.org>
> > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> Tested-by: Nathan Chancellor <nathan@kernel.org>
>
> > ---
> > Changes v2 -> v3:
> > * Drop check/requirement for LLVM=1, as per Masahiro.
> > * Change oneliner from LLVM=1 LLVM_IAS=1 to CC=clang LLVM_IAS=1.
> > * Don't carry forward Nathan's RB/TB tags. :( Sorry Nathan, but thank
> >    you for testing+reviewing v2.
> > * Update wording of docs slightly.
> >
> > Changes v1 -> v2:
> > * Fix typos in commit message as per Geert and Masahiro.
> > * Use SRCARCH instead of ARCH, simplifying x86 handling, as per
> >    Masahiro. Add his sugguested by tag.
> > * change commit oneline from 'drop' to 'infer.'
> > * Add detail about explicit host --target and relationship of ARCH to
> >    SRCARCH, as per Masahiro.
> >
> > Changes RFC -> v1:
> > * Rebase onto linux-kbuild/for-next
> > * Keep full target triples since missing the gnueabi suffix messes up
> >    32b ARM. Drop Fangrui's sugguested by tag. Update commit message to
> >    drop references to arm64.
> > * Flush out TODOS.
> > * Add note about -EL/-EB, -m32/-m64.
> > * Add note to Documentation/.
> >
> >   Documentation/kbuild/llvm.rst |  6 ++++++
> >   scripts/Makefile.clang        | 32 ++++++++++++++++++++++++++++++--
> >   2 files changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
> > index b18401d2ba82..aef1587fc09b 100644
> > --- a/Documentation/kbuild/llvm.rst
> > +++ b/Documentation/kbuild/llvm.rst
> > @@ -46,6 +46,12 @@ example: ::
> >
> >       clang --target=aarch64-linux-gnu foo.c
> >
> > +When both ``CC=clang`` (set via ``LLVM=1``) and ``LLVM_IAS=1`` are used,
> > +``CROSS_COMPILE`` becomes unnecessary and can be inferred from ``ARCH``.
>
> I am not a fan of this sentence because it implies that something like
> 'make ARCH=arm64 CC=clang LLVM_IAS=1' will work fine, which is not true.
> We still need CROSS_COMPILE for binutils in this configuration.


Agree.  That sentence is misleading, and moreover, it is wrong.



>
> CROSS_COMPILE provides the value for '--target=' and the prefix for the
> GNU tools such as ld, objcopy, and readelf. I think this direction is a
> regression because we are just talking about the first use of
> CROSS_COMPILE rather than the second at the same time.
>
> With LLVM=1 LLVM_IAS=1, we KNOW that the user will be using all LLVM
> tools. Sure, they are free to override LD, OBJCOPY, READELF, etc with
> the GNU variants but they have to provide the prefix because LLVM=1
> overrides the $(CROSS_COMPILE)<tool> assignments so it is irrelevant to
> us. As Masahiro mentioned, the user is free to individually specify all
> the tools by their individual variables such as LD=ld.lld BUT at that
> point, the user should be aware of what they are doing and specify
> CROSS_COMPILE.
>
> While I understand that the LLVM=1 LLVM_IAS=1 case works perfectly fine
> with this series, I am of the belief that making it work for CC=clang
> LLVM_IAS=1 is a mistake because there is no way for that configuration
> to work for cross compiling without CROSS_COMPILE.



LLVM=1 is a too strong requirement.


LLVM=1 switches not only target tools
(CC=clang, LD=ld.lld, AR=llvm-ar...)
but also host tools
(HOSTCC=clang, HOSTCXX=g++...).

Obviously host-tools are don't-care here.



Specifying the target tools individually, as in

   make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \
     OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf

... is a perfectly correct command that
makes CROSS_COMPILE unnecessary.

There is no reason to stop inferring --target for this case.


The problem is NOT removing the LLVM=1 check
but the wrong documentation.


Let's write a precise document.

For example, the following document exactly
explains what is happening in the code,
and is still clear.




diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index b18401d2ba82..a0d862bd73ac 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -63,6 +63,26 @@ They can be enabled individually. The full list of
the parameters: ::
 Currently, the integrated assembler is disabled by default. You can pass
 ``LLVM_IAS=1`` to enable it.

+
+Omitting CROSS_COMPILE
+----------------------
+
+As explained above, ``CROSS_COMPILE`` is used to set ``--target=<triple>``.
+
+Unless ``LLVM_IAS=1`` is specified, ``CROSS_COMPILE`` is also used to derive
+``--prefix=<path>`` to search for the back-end GNU assembler.
+
+If CROSS_COMPILE is not specified, the ``--target=<triple>`` is inferred from
+``ARCH``.
+
+It means, if you use only LLVM tools, `CROSS_COMPILE`` becomes unnecessary.
+
+For example, to cross-compile the arm64 kernel::
+
+       ARCH=arm64 make LLVM=1 LLVM_IAS=1
+
+
 Supported Architectures
 -----------------------





BTW, I noticed LLVM_IAS=1 check is also unneeded
for the same reason.
So, it should go away.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v3 2/2] Makefile: infer CROSS_COMPILE from SRCARCH for CC=clang LLVM_IAS=1

[Masahiro Yamada]

On Fri, Jul 30, 2021 at 9:19 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Thu, Jul 29, 2021 at 2:00 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > While I understand that the LLVM=1 LLVM_IAS=1 case works perfectly fine
> > with this series, I am of the belief that making it work for CC=clang
> > LLVM_IAS=1 is a mistake because there is no way for that configuration
> > to work for cross compiling without CROSS_COMPILE.
>
> So with v3 of this change, rather than:
>
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make CC=clang -j72
>
> If you wanted to omit CROSS_COMPILE, you'd need:
>
> $ ARCH=arm64 make CC=clang LLVM_IAS=1 LD=ld.lld OBJCOPY=llvm-objcopy
> STRIP=llvm-strip
>
> or
>
> $ ARCH=arm64 make CC=clang LLVM_IAS=1 LD=aarch64-linux-gnu-ld
> OBJCOPY=aarch64-linux-gnu-objcopy STRIP=aarch64-linux-gnu-strip

or

  $ ARCH=arm64 make LLVM=1 LLVM_IAS=1

still works.




> That's straight up worse IMO and defeats the purpose of "shortening
> the command line," which should be the goal.  Not "making CC=clang
> maximally flexible."  We don't want folks generally using CC=clang;
> preferably they'd use LLVM=1.  I need to rewrite our docs to make that
> more explicit and straightforward.  And if folks would prefer to use
> CC=clang for whatever reason, let them explicitly state CROSS_COMPILE
> then.
>
> So I agree with Nathan, and hope Masahiro will reconsider that perhaps
> the v2 variant that required LLVM=1 maybe makes more sense.


We can always infer the target triple from ARCH unless CROSS_COMPILE is given.

Doing this all the time makes nothing wrong.

"Whether CROSS_COMPILE is unneeded" is a different thing.



> Either way, I need to fix the comment in the new script, commit
> message, and docs, so v4 is necessary.
>
> I'm tempted to add a rewrite of our docs to say "just use LLVM=1"
> front and center, then get into finer grain details below, moving this
> second patch to be the third in a series.  Let's see what Masahiro's
> thoughts are though first. (I do appreciate them, even when I
> disagree).


I am not sure about that.

LLVM=1 is a very strong all-or-nothing flag,
but technically there is no reason to force it.

(At least, target-tools and host-tools look
independent to each other to me)


When you send v4, one more request:
Please drop LLVM_IAS=1 check as well.


-- 
Best Regards
Masahiro Yamada