All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
@ 2021-07-07 22:43 Nick Desaulniers
  2021-07-07 22:43 ` [PATCH 1/2] Makefile: move initial clang flag handling into scripts/Makefile.clang Nick Desaulniers
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-07 22:43 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Miguel Ojeda, Fangrui Song, Michal Marek, Arnd Bergmann,
	linux-kernel, linux-kbuild, clang-built-linux, 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 ARCH, and move some flag handling into a
new file included from the top level Makefile.

Nick Desaulniers (2):
  Makefile: move initial clang flag handling into scripts/Makefile.clang
  Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1

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


base-commit: a0e781a2a35a8dd4e6a38571998d59c6b0e32cd8
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH 1/2] Makefile: move initial clang flag handling into scripts/Makefile.clang
  2021-07-07 22:43 [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1 Nick Desaulniers
@ 2021-07-07 22:43 ` Nick Desaulniers
  2021-07-07 22:43 ` [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1 Nick Desaulniers
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-07 22:43 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Miguel Ojeda, Fangrui Song, Michal Marek, Arnd Bergmann,
	linux-kernel, linux-kbuild, clang-built-linux, 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/.

Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Changes RFC -> v1:
* Rename new file as per Nathan.

 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.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-07 22:43 [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1 Nick Desaulniers
  2021-07-07 22:43 ` [PATCH 1/2] Makefile: move initial clang flag handling into scripts/Makefile.clang Nick Desaulniers
@ 2021-07-07 22:43 ` Nick Desaulniers
  2021-07-08  8:08   ` Geert Uytterhoeven
  2021-07-08 10:21   ` Masahiro Yamada
  2021-07-08  5:49 ` [PATCH 0/2] infer CROSS_COMPILE from ARCH " Christoph Hellwig
  2021-07-19 21:10 ` Nick Desaulniers
  3 siblings, 2 replies; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-07 22:43 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Miguel Ojeda, Fangrui Song, Michal Marek, Arnd Bergmann,
	linux-kernel, linux-kbuild, clang-built-linux, Nick Desaulniers,
	Nathan Chancellor

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.

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

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

Link: https://github.com/ClangBuiltLinux/linux/issues/1399
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
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 |  5 +++++
 scripts/Makefile.clang        | 38 +++++++++++++++++++++++++++++++++--
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
index b18401d2ba82..80c63dd9a6d1 100644
--- a/Documentation/kbuild/llvm.rst
+++ b/Documentation/kbuild/llvm.rst
@@ -46,6 +46,11 @@ example: ::
 
 	clang --target=aarch64-linux-gnu foo.c
 
+When both ``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..a79088797a50 100644
--- a/scripts/Makefile.clang
+++ b/scripts/Makefile.clang
@@ -1,6 +1,40 @@
-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),)
+ifneq ($(LLVM),)
+ifeq ($(LLVM_IAS),1)
+ifeq ($(ARCH),arm)
+CLANG_FLAGS	+= --target=arm-linux-gnueabi
+else ifeq ($(ARCH),arm64)
+CLANG_FLAGS	+= --target=aarch64-linux-gnu
+else ifeq ($(ARCH),hexagon)
+CLANG_FLAGS	+= --target=hexagon-linux-gnu
+else ifeq ($(ARCH),i386)
+CLANG_FLAGS	+= --target=i686-linux-gnu
+else ifeq ($(ARCH),m68k)
+CLANG_FLAGS	+= --target=m68k-linux-gnu
+else ifeq ($(ARCH),mips)
+CLANG_FLAGS	+= --target=mipsel-linux-gnu
+else ifeq ($(ARCH),powerpc)
+CLANG_FLAGS	+= --target=powerpc64le-linux-gnu
+else ifeq ($(ARCH),riscv)
+CLANG_FLAGS	+= --target=riscv64-linux-gnu
+else ifeq ($(ARCH),s390)
+CLANG_FLAGS	+= --target=s390x-linux-gnu
+else ifeq ($(ARCH),x86)
+CLANG_FLAGS	+= --target=x86_64-linux-gnu
+else ifeq ($(ARCH),x86_64)
+CLANG_FLAGS	+= --target=x86_64-linux-gnu
+else
+$(error Specify CROSS_COMPILE or add '--target=' option to scripts/Makefile.clang)
+endif # ARCH
+endif # LLVM_IAS
+endif # LLVM
+else
 CLANG_FLAGS	+= --target=$(notdir $(CROSS_COMPILE:%-=%))
-endif
+endif # CROSS_COMPILE
+
 ifeq ($(LLVM_IAS),1)
 CLANG_FLAGS	+= -integrated-as
 else
-- 
2.32.0.93.g670b81a890-goog


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-07 22:43 [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1 Nick Desaulniers
  2021-07-07 22:43 ` [PATCH 1/2] Makefile: move initial clang flag handling into scripts/Makefile.clang Nick Desaulniers
  2021-07-07 22:43 ` [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1 Nick Desaulniers
@ 2021-07-08  5:49 ` Christoph Hellwig
  2021-07-08  7:27   ` Arnd Bergmann
  2021-07-19 21:10 ` Nick Desaulniers
  3 siblings, 1 reply; 17+ messages in thread
From: Christoph Hellwig @ 2021-07-08  5:49 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Masahiro Yamada, Miguel Ojeda, Fangrui Song, Michal Marek,
	Arnd Bergmann, linux-kernel, linux-kbuild, clang-built-linux,
	Linus Torvalds

On Wed, Jul 07, 2021 at 03:43:08PM -0700, 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 ARCH.
> 
> Instead, let's infer it from ARCH, and move some flag handling into a
> new file included from the top level Makefile.

Why only for LLVM?  I really hate the mess we currently have with
ARCH and CROSS_COMPILE.  Being able to set both in .config (and maybe
even inferring CROSS_COMPILE where possible) would make my life so
much easier.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-08  5:49 ` [PATCH 0/2] infer CROSS_COMPILE from ARCH " Christoph Hellwig
@ 2021-07-08  7:27   ` Arnd Bergmann
  2021-07-08 18:04     ` Nick Desaulniers
  0 siblings, 1 reply; 17+ messages in thread
From: Arnd Bergmann @ 2021-07-08  7:27 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: Nick Desaulniers, Masahiro Yamada, Miguel Ojeda, Fangrui Song,
	Michal Marek, Linux Kernel Mailing List,
	Linux Kbuild mailing list, clang-built-linux, Linus Torvalds

On Thu, Jul 8, 2021 at 7:49 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Wed, Jul 07, 2021 at 03:43:08PM -0700, 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 ARCH.
> >
> > Instead, let's infer it from ARCH, and move some flag handling into a
> > new file included from the top level Makefile.
>
> Why only for LLVM?  I really hate the mess we currently have with
> ARCH and CROSS_COMPILE.  Being able to set both in .config (and maybe
> even inferring CROSS_COMPILE where possible) would make my life so
> much easier.

I agree this would be best, but solving the problem for llvm is
trivial with a 1:1
mapping between ARCH= and --target= strings. Doing the same for gcc
requires enumerating all possible target triples, and possibly deciding between
different versions, e.g. when your path contains

/usr/bin/powerpc64-linux-gnu-gcc-5.2.0
/usr/bin/powerpc64-linux-gnu-gcc -> powerpc64-linux-gnu-gcc-5.2.0
/usr/local/bin/ppc64le-linux-gcc-9
~/bin/powerpc/powerpc-linux-unknown-gcc-12.0.20210708.experimental

all of these should be able to cross-build any powerpc kernel, but
there is no obvious first choice (highest version, first in path,
ordered list of target triples, ...). I tried coming up with a heuristic
to pick a reasonable toolchain, but at some point gave up because
I failed to express that in a readable bash or Makefile syntax.

        Arnd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-07 22:43 ` [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1 Nick Desaulniers
@ 2021-07-08  8:08   ` Geert Uytterhoeven
  2021-07-08  8:44     ` Masahiro Yamada
  2021-07-08 10:21   ` Masahiro Yamada
  1 sibling, 1 reply; 17+ messages in thread
From: Geert Uytterhoeven @ 2021-07-08  8:08 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Masahiro Yamada, Miguel Ojeda, Fangrui Song, Michal Marek,
	Arnd Bergmann, Linux Kernel Mailing List, linux-kbuild,
	clang-built-linux, Nathan Chancellor

Hi Nick,

On Thu, Jul 8, 2021 at 1:12 AM Nick Desaulniers <ndesaulniers@google.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 ARCH.
>
> If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> KBUILD_CFLAGS, and KBUILD_AFLAGS based on $ARCH.
>
> Previously, we'd cross compile via:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linxu-gnu make LLVM=1 LLVM_IAS=1

Which didn't really work, I assume? (s/linxu/linux/)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-08  8:08   ` Geert Uytterhoeven
@ 2021-07-08  8:44     ` Masahiro Yamada
  0 siblings, 0 replies; 17+ messages in thread
From: Masahiro Yamada @ 2021-07-08  8:44 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Nick Desaulniers, Miguel Ojeda, Fangrui Song, Michal Marek,
	Arnd Bergmann, Linux Kernel Mailing List, linux-kbuild,
	clang-built-linux, Nathan Chancellor

On Thu, Jul 8, 2021 at 5:08 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Nick,
>
> On Thu, Jul 8, 2021 at 1:12 AM Nick Desaulniers <ndesaulniers@google.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 ARCH.
> >
> > If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> > KBUILD_CFLAGS, and KBUILD_AFLAGS based on $ARCH.
> >
> > Previously, we'd cross compile via:
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linxu-gnu make LLVM=1 LLVM_IAS=1
>
> Which didn't really work, I assume? (s/linxu/linux/)

Also
s/gnu/gnu-/



-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-07 22:43 ` [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1 Nick Desaulniers
  2021-07-08  8:08   ` Geert Uytterhoeven
@ 2021-07-08 10:21   ` Masahiro Yamada
  2021-07-08 11:44     ` Arnd Bergmann
  2021-07-08 19:02     ` Nick Desaulniers
  1 sibling, 2 replies; 17+ messages in thread
From: Masahiro Yamada @ 2021-07-08 10:21 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Miguel Ojeda, Fangrui Song, Michal Marek, Arnd Bergmann,
	Linux Kernel Mailing List, Linux Kbuild mailing list,
	clang-built-linux, Nathan Chancellor

On Thu, Jul 8, 2021 at 7:43 AM '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 ARCH.
>
> If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> KBUILD_CFLAGS, and KBUILD_AFLAGS based on $ARCH.
>
> Previously, we'd cross compile via:
> $ ARCH=arm64 CROSS_COMPILE=aarch64-linxu-gnu make LLVM=1 LLVM_IAS=1
> Now:
> $ ARCH=arm64 make LLVM=1 LLVM_IAS=1
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1399
> Suggested-by: Arnd Bergmann <arnd@kernel.org>
> Suggested-by: Nathan Chancellor <nathan@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> 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 |  5 +++++
>  scripts/Makefile.clang        | 38 +++++++++++++++++++++++++++++++++--
>  2 files changed, 41 insertions(+), 2 deletions(-)








When I was considering a similar idea, my plan was
to implement this in Kconfig instead of in Makefile
because that will pass the compiler information
in one direction (only from Kconfig to Kbuild), but
that is not so important. We can change it later
if needed.

I did not complete it because I was investigating
some issues (especially [3] below), but maybe
that is something we don't care about.

Can you address [2] below at least?
If we do not have any concern, I can merge it.
It is likely so because people are only discussing
"We want to omit omit CROSS_COMPILE".







[1] explicit target triple for native builds

The default target of my distro clang
is x86_64-pc-linux-gnu.

$ clang --version
Ubuntu clang version 11.0.0-2
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

So, previously, the kernel was built with
implied --target=x86_64-pc-linux-gnu.


With this patch, --target=x86_64-linux-gnu will be
explicitly specified.

The same applies to native-builds of other architectures.
For example, when a user builds the arm64 kernel on
an arm64 server, --target=aarch64-linux-gnu is
explicitly forced.

I guess, this is a good direction because the produced
code will be more deterministic, irrespective of the
Clang's configuration.



[2] 32/64-bit configuration is toggled in Kconfig time.

Initially, you submitted only arm64. Maybe, it was intentional
since arm64 is the simplest case.

In the kernel tree, arch/arm and arch/arm64 are very special
cases where 32-bit and 64-bit are separated by directory.

Some of the other architectures are bi-arch, and
32-bit/64-bit is specified by CONFIG_64BIT in Kconfig time.

When Makefiles are being parsed, we actually do not know
whether the user is planning to configure the kernel
for 32-bit or 64-bit because CONFIG_64BIT is not
specified at this point.

ARCH=x86 + CONFIG_64BIT=y
will build the x86_64 kernel, and
ARCH=x86 + CONFIG_64BIT=n
will build the i386 kernel.


Then, you may wonder

  else ifeq ($(ARCH),x86)
  CLANG_FLAGS    += --target=x86_64-linux-gnu

... works?

Yes, it does fortunately.

-m32/-m64 takes precedence over the
{x86_64,i386} part of the target triple.

As far as I tested,

      clang --target=x86_64-linux-gnu -m32

produced i386 code.

Interestingly,

    clang --target=i386-linux-gnu  -m64

produced x86_64 code.


We must rely on this behavior of Clang because
--target (which is contained in CLANG_FLAGS)
must be specified before the Kconfig time.
Then, a user can toggle CONFIG_64BIT any time
from menuconfig etc.

With this in mind, using $(ARCH) as if-else
switches is pointless.
$(SRCARCH) is the only meaningful input.


  else ifeq ($(ARCH),i386)
  CLANG_FLAGS    += --target=i686-linux-gnu
  else ifeq ($(ARCH),x86)
  CLANG_FLAGS    += --target=x86_64-linux-gnu
  else ifeq ($(ARCH),x86_64)
  CLANG_FLAGS    += --target=x86_64-linux-gnu

should be replaced with:

  else ifeq ($(SRCARCH),x86_64)
  CLANG_FLAGS    += --target=x86_64-linux-gnu


Some architectures are not only bi-arch, but also bi-endian.


You hardcoded 64bit little endian for ppc:

   else ifeq ($(ARCH),powerpc)
   CLANG_FLAGS    += --target=powerpc64le-linux-gnu


But, we must rely on the fact that

   clang  --target=powerpc64le-linux-gnu -mbig-endian -m32

produces big-endian 32-bit code.

This makes the "64le" part meaningless.


This should be noted. Otherwise it is difficult
to understand why --target=x86_64-linux-gnu works fine
with building the i386 kernel.



[3] User-space compilation

This does not matter to the kernel itself, but
Kbuild compiles some userspace programs for
the target architecture.
See the samples/ directory for example.

Another example is net/bpfilter/Makefile, which
embeds the user mode helper when
CONFIG_BPFILTER_UMH=y.

For this purpose, Kconfig checks if $(CC) is
capable of linking the userspace.
(CONFIG_CC_CAN_LINK).

When cross-building with Clang, I cannot see
CONFIG_CC_CAN_LINK set.

If we care about CONFIG_CC_CAN_LINK, probably,
--sysroot or something should be set according to:

https://clang.llvm.org/docs/CrossCompilation.html

This is an existing issue, but I have no time
for looking into this.

On debian systems, sysroot for cross-compilation
are located in /usr/aarch64-linux-gnu,
/usr/arm-linux-gnueabi, /usr/arm-linux-gnueabihf,
/usr/i686-linux-gnu/ etc. but I do not know if it
is the same across distros.





[4] What is the best target if we hard-code it?

Currently, we require the correct CROSS_COMPILE
is provided by users.

The target might impact the performance
or the ABI.
It was difficult for me to define
which one is better than another.

For example for ARCH=arm, which is better
--target=arm-linux-gnueabi or
--target=arm-lnux-gnueabihf or
something we don't care about?







> diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst
> index b18401d2ba82..80c63dd9a6d1 100644
> --- a/Documentation/kbuild/llvm.rst
> +++ b/Documentation/kbuild/llvm.rst
> @@ -46,6 +46,11 @@ example: ::
>
>         clang --target=aarch64-linux-gnu foo.c
>
> +When both ``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..a79088797a50 100644
> --- a/scripts/Makefile.clang
> +++ b/scripts/Makefile.clang
> @@ -1,6 +1,40 @@
> -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),)
> +ifneq ($(LLVM),)
> +ifeq ($(LLVM_IAS),1)
> +ifeq ($(ARCH),arm)
> +CLANG_FLAGS    += --target=arm-linux-gnueabi
> +else ifeq ($(ARCH),arm64)
> +CLANG_FLAGS    += --target=aarch64-linux-gnu
> +else ifeq ($(ARCH),hexagon)
> +CLANG_FLAGS    += --target=hexagon-linux-gnu
> +else ifeq ($(ARCH),i386)
> +CLANG_FLAGS    += --target=i686-linux-gnu
> +else ifeq ($(ARCH),m68k)
> +CLANG_FLAGS    += --target=m68k-linux-gnu
> +else ifeq ($(ARCH),mips)
> +CLANG_FLAGS    += --target=mipsel-linux-gnu
> +else ifeq ($(ARCH),powerpc)
> +CLANG_FLAGS    += --target=powerpc64le-linux-gnu
> +else ifeq ($(ARCH),riscv)
> +CLANG_FLAGS    += --target=riscv64-linux-gnu
> +else ifeq ($(ARCH),s390)
> +CLANG_FLAGS    += --target=s390x-linux-gnu
> +else ifeq ($(ARCH),x86)
> +CLANG_FLAGS    += --target=x86_64-linux-gnu
> +else ifeq ($(ARCH),x86_64)
> +CLANG_FLAGS    += --target=x86_64-linux-gnu
> +else
> +$(error Specify CROSS_COMPILE or add '--target=' option to scripts/Makefile.clang)
> +endif # ARCH
> +endif # LLVM_IAS
> +endif # LLVM
> +else
>  CLANG_FLAGS    += --target=$(notdir $(CROSS_COMPILE:%-=%))
> -endif
> +endif # CROSS_COMPILE
> +
>  ifeq ($(LLVM_IAS),1)
>  CLANG_FLAGS    += -integrated-as
>  else
> --
> 2.32.0.93.g670b81a890-goog
>
> --
> 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/20210707224310.1403944-3-ndesaulniers%40google.com.



--
Best Regards

Masahiro Yamada

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-08 10:21   ` Masahiro Yamada
@ 2021-07-08 11:44     ` Arnd Bergmann
  2021-07-08 19:06       ` Nick Desaulniers
  2021-07-08 19:02     ` Nick Desaulniers
  1 sibling, 1 reply; 17+ messages in thread
From: Arnd Bergmann @ 2021-07-08 11:44 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Nick Desaulniers, Miguel Ojeda, Fangrui Song, Michal Marek,
	Linux Kernel Mailing List, Linux Kbuild mailing list,
	clang-built-linux, Nathan Chancellor

On Thu, Jul 8, 2021 at 12:23 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> On Thu, Jul 8, 2021 at 7:43 AM 'Nick Desaulniers' via Clang Built
>
> We must rely on this behavior of Clang because
> --target (which is contained in CLANG_FLAGS)
> must be specified before the Kconfig time.
> Then, a user can toggle CONFIG_64BIT any time
> from menuconfig etc.
>
> With this in mind, using $(ARCH) as if-else
> switches is pointless.
> $(SRCARCH) is the only meaningful input.
>
>
>   else ifeq ($(ARCH),i386)
>   CLANG_FLAGS    += --target=i686-linux-gnu
>   else ifeq ($(ARCH),x86)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu
>   else ifeq ($(ARCH),x86_64)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu
>
> should be replaced with:
>
>   else ifeq ($(SRCARCH),x86_64)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu

I think we usually only have to provide the architecture
name, as in "--target=x86_64", though for arm I get a
warning "clang: warning: unknown platform, assuming
-mfloat-abi=soft" unless I provide the full triple.

> For example for ARCH=arm, which is better
> --target=arm-linux-gnueabi or
> --target=arm-lnux-gnueabihf or something we don't care about?

The kernel is always soft-float itself, so it does not matter either way.

       Arnd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-08  7:27   ` Arnd Bergmann
@ 2021-07-08 18:04     ` Nick Desaulniers
  2021-07-09  8:07       ` Arnd Bergmann
  0 siblings, 1 reply; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-08 18:04 UTC (permalink / raw)
  To: Arnd Bergmann, Christoph Hellwig
  Cc: Masahiro Yamada, Miguel Ojeda, Fangrui Song, Michal Marek,
	Linux Kernel Mailing List, Linux Kbuild mailing list,
	clang-built-linux, Linus Torvalds

On Thu, Jul 8, 2021 at 12:27 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Jul 8, 2021 at 7:49 AM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > On Wed, Jul 07, 2021 at 03:43:08PM -0700, 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 ARCH.
> > >
> > > Instead, let's infer it from ARCH, and move some flag handling into a
> > > new file included from the top level Makefile.
> >
> > Why only for LLVM?  I really hate the mess we currently have with
> > ARCH and CROSS_COMPILE.

I agree.

> > Being able to set both in .config (and maybe
> > even inferring CROSS_COMPILE where possible) would make my life so
> > much easier.
>
> I agree this would be best, but solving the problem for llvm is
> trivial with a 1:1
> mapping between ARCH= and --target= strings. Doing the same for gcc
> requires enumerating all possible target triples, and possibly deciding between
> different versions, e.g. when your path contains

Yes. There is a seldom used Kbuild macro for this: cc-cross-prefix.
It's hard coded to check for prefixed versions of gcc, but it will
handle the enumeration. Perhaps it could be used more widely, once we
know whether we're building with gcc or clang.  But as you note,
enumeration is kind of a waste of time for clang as these target
triples are known ahead of time.  I guess we could check that your
build of clang was configured with support for that target ARCH (since
you can disable backends when building clang), but I consider
disabling backends an antipattern, and I think the user will figure
out pretty quickly when they're trying to build a target that LLVM
doesn't support (whether due to configured-off or unimplemented
target).

> /usr/bin/powerpc64-linux-gnu-gcc-5.2.0
> /usr/bin/powerpc64-linux-gnu-gcc -> powerpc64-linux-gnu-gcc-5.2.0
> /usr/local/bin/ppc64le-linux-gcc-9
> ~/bin/powerpc/powerpc-linux-unknown-gcc-12.0.20210708.experimental
>
> all of these should be able to cross-build any powerpc kernel, but
> there is no obvious first choice (highest version, first in path,
> ordered list of target triples, ...). I tried coming up with a heuristic
> to pick a reasonable toolchain, but at some point gave up because
> I failed to express that in a readable bash or Makefile syntax.

Right; foremost in my mind was arm-linux-gnueabi-gcc vs
arm-linux-gnueabihf-gcc.  That's not even to mention the versioned
suffixes.

In terms of multiversion support; this series doesn't regress doing
things the hard/verbose way.  But I think for most users we can have a
simpler common case; folks can play with their $PATH or focus on more
hermetic builds if they want this new feature (CROSS_COMPILE
inference) AND support for multiple versions of the same toolchain.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-08 10:21   ` Masahiro Yamada
  2021-07-08 11:44     ` Arnd Bergmann
@ 2021-07-08 19:02     ` Nick Desaulniers
  2021-07-08 19:47       ` Masahiro Yamada
  1 sibling, 1 reply; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-08 19:02 UTC (permalink / raw)
  To: Masahiro Yamada, Fangrui Song
  Cc: Miguel Ojeda, Michal Marek, Arnd Bergmann,
	Linux Kernel Mailing List, Linux Kbuild mailing list,
	clang-built-linux, Nathan Chancellor

On Thu, Jul 8, 2021 at 3:23 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Thu, Jul 8, 2021 at 7:43 AM '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 ARCH.
> >
> > If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> > KBUILD_CFLAGS, and KBUILD_AFLAGS based on $ARCH.
> >
> > Previously, we'd cross compile via:
> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linxu-gnu make LLVM=1 LLVM_IAS=1
> > Now:
> > $ ARCH=arm64 make LLVM=1 LLVM_IAS=1
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1399
> > Suggested-by: Arnd Bergmann <arnd@kernel.org>
> > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > 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 |  5 +++++
> >  scripts/Makefile.clang        | 38 +++++++++++++++++++++++++++++++++--
> >  2 files changed, 41 insertions(+), 2 deletions(-)
>
>
>
>
>
>
>
>
> When I was considering a similar idea, my plan was
> to implement this in Kconfig instead of in Makefile
> because that will pass the compiler information
> in one direction (only from Kconfig to Kbuild), but
> that is not so important. We can change it later
> if needed.
>
> I did not complete it because I was investigating
> some issues (especially [3] below), but maybe
> that is something we don't care about.
>
> Can you address [2] below at least?

Sure!

> If we do not have any concern, I can merge it.
> It is likely so because people are only discussing
> "We want to omit omit CROSS_COMPILE".
>
>
>
>
>
>
>
> [1] explicit target triple for native builds
>
> The default target of my distro clang
> is x86_64-pc-linux-gnu.
>
> $ clang --version
> Ubuntu clang version 11.0.0-2
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
>
> So, previously, the kernel was built with
> implied --target=x86_64-pc-linux-gnu.
>
>
> With this patch, --target=x86_64-linux-gnu will be
> explicitly specified.

Correct. We've been doing this for x86 builds of Android kernels for a
while without issue.

I can add this note to the commit message:
```
For native builds (not involving cross compilation) we now explicitly
specify a target triple
rather than rely on the implicit host triple.
```
The only downside I can think of now is that we've encountered E2BIG
for excessively long command line arguments in the past (mostly for
out of tree drivers in Android).  I'm having trouble imagining how the
implicit host triple could differ in a way from these explicit ones
that would break native compilation.  Then again, someone did just
submit patches for building Linux on BSD.

If we don't want to do that, perhaps we could check `cross_compiling`.
Why did you make that variable lowercase in
commit f02aa48dde8b ("kconfig: use /boot/config-* etc. as
DEFCONFIG_LIST only for native build")?
Because the "origin" is not the environment?

> The same applies to native-builds of other architectures.
> For example, when a user builds the arm64 kernel on
> an arm64 server, --target=aarch64-linux-gnu is
> explicitly forced.
>
> I guess, this is a good direction because the produced
> code will be more deterministic, irrespective of the
> Clang's configuration.
>
>
>
> [2] 32/64-bit configuration is toggled in Kconfig time.
>
> Initially, you submitted only arm64. Maybe, it was intentional
> since arm64 is the simplest case.
>
> In the kernel tree, arch/arm and arch/arm64 are very special
> cases where 32-bit and 64-bit are separated by directory.
>
> Some of the other architectures are bi-arch, and
> 32-bit/64-bit is specified by CONFIG_64BIT in Kconfig time.
>
> When Makefiles are being parsed, we actually do not know
> whether the user is planning to configure the kernel
> for 32-bit or 64-bit because CONFIG_64BIT is not
> specified at this point.
>
> ARCH=x86 + CONFIG_64BIT=y
> will build the x86_64 kernel, and
> ARCH=x86 + CONFIG_64BIT=n
> will build the i386 kernel.
>
>
> Then, you may wonder
>
>   else ifeq ($(ARCH),x86)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu
>
> ... works?
>
> Yes, it does fortunately.
>
> -m32/-m64 takes precedence over the
> {x86_64,i386} part of the target triple.
>
> As far as I tested,
>
>       clang --target=x86_64-linux-gnu -m32
>
> produced i386 code.
>
> Interestingly,
>
>     clang --target=i386-linux-gnu  -m64
>
> produced x86_64 code.

Correct. -m32/-m64 and -LE/-BE refine the target triple that the
driver builds up.

> We must rely on this behavior of Clang because
> --target (which is contained in CLANG_FLAGS)
> must be specified before the Kconfig time.
> Then, a user can toggle CONFIG_64BIT any time
> from menuconfig etc.

Correct. So we can't quite move all clang flags into one Makefile
under scripts/ if they rely on Kconfig being run first. This new
makefile is a "pre-kconfig" set of flags.

> With this in mind, using $(ARCH) as if-else
> switches is pointless.
> $(SRCARCH) is the only meaningful input.
>
>
>   else ifeq ($(ARCH),i386)
>   CLANG_FLAGS    += --target=i686-linux-gnu
>   else ifeq ($(ARCH),x86)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu
>   else ifeq ($(ARCH),x86_64)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu
>
> should be replaced with:
>
>   else ifeq ($(SRCARCH),x86_64)
>   CLANG_FLAGS    += --target=x86_64-linux-gnu

Sure, it looks like this would simplify the i386 vs x86_64 handling,
and the use of SRCARCH does seem more prevalent throughout the
codebase. I will fix in v2.

> Some architectures are not only bi-arch, but also bi-endian.
>
>
> You hardcoded 64bit little endian for ppc:
>
>    else ifeq ($(ARCH),powerpc)
>    CLANG_FLAGS    += --target=powerpc64le-linux-gnu
>
>
> But, we must rely on the fact that
>
>    clang  --target=powerpc64le-linux-gnu -mbig-endian -m32
>
> produces big-endian 32-bit code.
>
> This makes the "64le" part meaningless.
>
>
> This should be noted. Otherwise it is difficult

It is noted; in the top part of the newly added make file.
```
  1 # Individual arch/{arch}/Makfiles should use -EL/-EB to set
intended endianness
  2 # and -m32/-m64 to set word size based on Kconfigs instead of
relying on the
  3 # target triple.
```
Is there somewhere/somehow else you'd like me to note that?

> to understand why --target=x86_64-linux-gnu works fine
> with building the i386 kernel.
>
>
>
> [3] User-space compilation
>
> This does not matter to the kernel itself, but
> Kbuild compiles some userspace programs for
> the target architecture.
> See the samples/ directory for example.
>
> Another example is net/bpfilter/Makefile, which
> embeds the user mode helper when
> CONFIG_BPFILTER_UMH=y.
>
> For this purpose, Kconfig checks if $(CC) is
> capable of linking the userspace.
> (CONFIG_CC_CAN_LINK).
>
> When cross-building with Clang, I cannot see
> CONFIG_CC_CAN_LINK set.

Yes, that is a known issue.
https://github.com/ClangBuiltLinux/linux/issues/1290

>
> If we care about CONFIG_CC_CAN_LINK, probably,
> --sysroot or something should be set according to:
>
> https://clang.llvm.org/docs/CrossCompilation.html
>
> This is an existing issue, but I have no time
> for looking into this.
>
> On debian systems, sysroot for cross-compilation
> are located in /usr/aarch64-linux-gnu,
> /usr/arm-linux-gnueabi, /usr/arm-linux-gnueabihf,
> /usr/i686-linux-gnu/ etc. but I do not know if it
> is the same across distros.

Right. If I remember the glibc/binutils/gcc bootstrap dance, I thought
gcc was configured with a known path to a particular version of glibc.
So a cross toolchain knew where to look for its cross libc.

Clang doesn't have such configure time step; it can cross compile
easily with one binary, but cross linking a working executable is
still a PITA due to not knowing which cross libc to link against.  I'm
not sure whether we need to improve Clang's logic when cross compiling
to look in "sane default" paths for a cross libc, or if we should just
add some flag when cross compiling with clang in Kbuild (such as
--sysroot) in order for CONFIG_CC_CAN_LINK to work as expected.
Fangrui probably has a good opinion about this.

Zig (the compiler, but also the language name) can do this quite
nicely. I'm envious.
https://twitter.com/andy_kelley/status/1241409388532948992?lang=en
https://www.youtube.com/watch?v=pq1XqP4-qOo

But this is also somewhat orthogonal to the goal of "infer
CROSS_COMPILE (or really, --target=) from ARCH (or really, SRCARCH)" I
think.  It's still interesting for us all to discuss on-list though.

>
>
>
>
>
> [4] What is the best target if we hard-code it?
>
> Currently, we require the correct CROSS_COMPILE
> is provided by users.
>
> The target might impact the performance
> or the ABI.
> It was difficult for me to define
> which one is better than another.
>
> For example for ARCH=arm, which is better
> --target=arm-linux-gnueabi or
> --target=arm-lnux-gnueabihf or
> something we don't care about?

Yes, this is a case I was interested in.  I've used either
interchangeably without issue for years.  That's not to say we get the
same binary image with either.

I get the same .config for the defconfig target with either.

If I zero out KBUILD_BUILD_TIMESTAMP and the build number, I still get
different sha1sums.  Though that assumes clang, lld, and kbuild are
all deterministic, which I also haven't spent time to verify.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-08 11:44     ` Arnd Bergmann
@ 2021-07-08 19:06       ` Nick Desaulniers
  0 siblings, 0 replies; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-08 19:06 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Masahiro Yamada, Miguel Ojeda, Fangrui Song, Michal Marek,
	Linux Kernel Mailing List, Linux Kbuild mailing list,
	clang-built-linux, Nathan Chancellor

On Thu, Jul 8, 2021 at 4:45 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Jul 8, 2021 at 12:23 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> > On Thu, Jul 8, 2021 at 7:43 AM 'Nick Desaulniers' via Clang Built
> >
> > We must rely on this behavior of Clang because
> > --target (which is contained in CLANG_FLAGS)
> > must be specified before the Kconfig time.
> > Then, a user can toggle CONFIG_64BIT any time
> > from menuconfig etc.
> >
> > With this in mind, using $(ARCH) as if-else
> > switches is pointless.
> > $(SRCARCH) is the only meaningful input.
> >
> >
> >   else ifeq ($(ARCH),i386)
> >   CLANG_FLAGS    += --target=i686-linux-gnu
> >   else ifeq ($(ARCH),x86)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
> >   else ifeq ($(ARCH),x86_64)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
> >
> > should be replaced with:
> >
> >   else ifeq ($(SRCARCH),x86_64)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
>
> I think we usually only have to provide the architecture
> name, as in "--target=x86_64", though for arm I get a
> warning "clang: warning: unknown platform, assuming
> -mfloat-abi=soft" unless I provide the full triple.

Right, Fangrui also made that suggestion, but for that reason (the
error for various architectures when using 2-component triples) I'd
prefer to just always specify a full triple.  I picked some to have a
starting point; unless they NEED to change, I'll refrain from
modifying them further.

Technically, I think they can have 4 components, not sure why we still
call them a "target triple." I guess I wouldn't be surprised if they
can contain more than 4 components at this point.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
  2021-07-08 19:02     ` Nick Desaulniers
@ 2021-07-08 19:47       ` Masahiro Yamada
  0 siblings, 0 replies; 17+ messages in thread
From: Masahiro Yamada @ 2021-07-08 19:47 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Fangrui Song, Miguel Ojeda, Michal Marek, Arnd Bergmann,
	Linux Kernel Mailing List, Linux Kbuild mailing list,
	clang-built-linux, Nathan Chancellor

On Fri, Jul 9, 2021 at 4:02 AM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> On Thu, Jul 8, 2021 at 3:23 AM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >
> > On Thu, Jul 8, 2021 at 7:43 AM '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 ARCH.
> > >
> > > If CROSS_COMPILE is not set, simply set --target= for CLANG_FLAGS,
> > > KBUILD_CFLAGS, and KBUILD_AFLAGS based on $ARCH.
> > >
> > > Previously, we'd cross compile via:
> > > $ ARCH=arm64 CROSS_COMPILE=aarch64-linxu-gnu make LLVM=1 LLVM_IAS=1
> > > Now:
> > > $ ARCH=arm64 make LLVM=1 LLVM_IAS=1
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1399
> > > Suggested-by: Arnd Bergmann <arnd@kernel.org>
> > > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > > ---
> > > 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 |  5 +++++
> > >  scripts/Makefile.clang        | 38 +++++++++++++++++++++++++++++++++--
> > >  2 files changed, 41 insertions(+), 2 deletions(-)
> >
> >
> >
> >
> >
> >
> >
> >
> > When I was considering a similar idea, my plan was
> > to implement this in Kconfig instead of in Makefile
> > because that will pass the compiler information
> > in one direction (only from Kconfig to Kbuild), but
> > that is not so important. We can change it later
> > if needed.
> >
> > I did not complete it because I was investigating
> > some issues (especially [3] below), but maybe
> > that is something we don't care about.
> >
> > Can you address [2] below at least?
>
> Sure!
>
> > If we do not have any concern, I can merge it.
> > It is likely so because people are only discussing
> > "We want to omit omit CROSS_COMPILE".
> >
> >
> >
> >
> >
> >
> >
> > [1] explicit target triple for native builds
> >
> > The default target of my distro clang
> > is x86_64-pc-linux-gnu.
> >
> > $ clang --version
> > Ubuntu clang version 11.0.0-2
> > Target: x86_64-pc-linux-gnu
> > Thread model: posix
> > InstalledDir: /usr/bin
> >
> > So, previously, the kernel was built with
> > implied --target=x86_64-pc-linux-gnu.
> >
> >
> > With this patch, --target=x86_64-linux-gnu will be
> > explicitly specified.
>
> Correct. We've been doing this for x86 builds of Android kernels for a
> while without issue.
>
> I can add this note to the commit message:
> ```
> For native builds (not involving cross compilation) we now explicitly
> specify a target triple
> rather than rely on the implicit host triple.

Sounds good.


> ```
> The only downside I can think of now is that we've encountered E2BIG
> for excessively long command line arguments in the past (mostly for
> out of tree drivers in Android).  I'm having trouble imagining how the
> implicit host triple could differ in a way from these explicit ones
> that would break native compilation.  Then again, someone did just
> submit patches for building Linux on BSD.
>
> If we don't want to do that, perhaps we could check `cross_compiling`.
> Why did you make that variable lowercase in
> commit f02aa48dde8b ("kconfig: use /boot/config-* etc. as
> DEFCONFIG_LIST only for native build")?
> Because the "origin" is not the environment?

Yes, something like that.
I'd like to use upper cases for user interface.

I think using lower cases is OK for
internal variables, but the policy
may not be consistent.







> > The same applies to native-builds of other architectures.
> > For example, when a user builds the arm64 kernel on
> > an arm64 server, --target=aarch64-linux-gnu is
> > explicitly forced.
> >
> > I guess, this is a good direction because the produced
> > code will be more deterministic, irrespective of the
> > Clang's configuration.
> >
> >
> >
> > [2] 32/64-bit configuration is toggled in Kconfig time.
> >
> > Initially, you submitted only arm64. Maybe, it was intentional
> > since arm64 is the simplest case.
> >
> > In the kernel tree, arch/arm and arch/arm64 are very special
> > cases where 32-bit and 64-bit are separated by directory.
> >
> > Some of the other architectures are bi-arch, and
> > 32-bit/64-bit is specified by CONFIG_64BIT in Kconfig time.
> >
> > When Makefiles are being parsed, we actually do not know
> > whether the user is planning to configure the kernel
> > for 32-bit or 64-bit because CONFIG_64BIT is not
> > specified at this point.
> >
> > ARCH=x86 + CONFIG_64BIT=y
> > will build the x86_64 kernel, and
> > ARCH=x86 + CONFIG_64BIT=n
> > will build the i386 kernel.
> >
> >
> > Then, you may wonder
> >
> >   else ifeq ($(ARCH),x86)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
> >
> > ... works?
> >
> > Yes, it does fortunately.
> >
> > -m32/-m64 takes precedence over the
> > {x86_64,i386} part of the target triple.
> >
> > As far as I tested,
> >
> >       clang --target=x86_64-linux-gnu -m32
> >
> > produced i386 code.
> >
> > Interestingly,
> >
> >     clang --target=i386-linux-gnu  -m64
> >
> > produced x86_64 code.
>
> Correct. -m32/-m64 and -LE/-BE refine the target triple that the
> driver builds up.
>
> > We must rely on this behavior of Clang because
> > --target (which is contained in CLANG_FLAGS)
> > must be specified before the Kconfig time.
> > Then, a user can toggle CONFIG_64BIT any time
> > from menuconfig etc.
>
> Correct. So we can't quite move all clang flags into one Makefile
> under scripts/ if they rely on Kconfig being run first. This new
> makefile is a "pre-kconfig" set of flags.
>
> > With this in mind, using $(ARCH) as if-else
> > switches is pointless.
> > $(SRCARCH) is the only meaningful input.
> >
> >
> >   else ifeq ($(ARCH),i386)
> >   CLANG_FLAGS    += --target=i686-linux-gnu
> >   else ifeq ($(ARCH),x86)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
> >   else ifeq ($(ARCH),x86_64)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
> >
> > should be replaced with:
> >
> >   else ifeq ($(SRCARCH),x86_64)
> >   CLANG_FLAGS    += --target=x86_64-linux-gnu
>
> Sure, it looks like this would simplify the i386 vs x86_64 handling,
> and the use of SRCARCH does seem more prevalent throughout the
> codebase. I will fix in v2.
>
> > Some architectures are not only bi-arch, but also bi-endian.
> >
> >
> > You hardcoded 64bit little endian for ppc:
> >
> >    else ifeq ($(ARCH),powerpc)
> >    CLANG_FLAGS    += --target=powerpc64le-linux-gnu
> >
> >
> > But, we must rely on the fact that
> >
> >    clang  --target=powerpc64le-linux-gnu -mbig-endian -m32
> >
> > produces big-endian 32-bit code.
> >
> > This makes the "64le" part meaningless.
> >
> >
> > This should be noted. Otherwise it is difficult
>
> It is noted; in the top part of the newly added make file.
> ```
>   1 # Individual arch/{arch}/Makfiles should use -EL/-EB to set
> intended endianness
>   2 # and -m32/-m64 to set word size based on Kconfigs instead of
> relying on the
>   3 # target triple.
> ```
> Is there somewhere/somehow else you'd like me to note that?

Ah, you already noted it in the new Makefile.
Sorry, I missed it.

Then, this is fine.




>
> > to understand why --target=x86_64-linux-gnu works fine
> > with building the i386 kernel.
> >
> >
> >
> > [3] User-space compilation
> >
> > This does not matter to the kernel itself, but
> > Kbuild compiles some userspace programs for
> > the target architecture.
> > See the samples/ directory for example.
> >
> > Another example is net/bpfilter/Makefile, which
> > embeds the user mode helper when
> > CONFIG_BPFILTER_UMH=y.
> >
> > For this purpose, Kconfig checks if $(CC) is
> > capable of linking the userspace.
> > (CONFIG_CC_CAN_LINK).
> >
> > When cross-building with Clang, I cannot see
> > CONFIG_CC_CAN_LINK set.
>
> Yes, that is a known issue.
> https://github.com/ClangBuiltLinux/linux/issues/1290
>
> >
> > If we care about CONFIG_CC_CAN_LINK, probably,
> > --sysroot or something should be set according to:
> >
> > https://clang.llvm.org/docs/CrossCompilation.html
> >
> > This is an existing issue, but I have no time
> > for looking into this.
> >
> > On debian systems, sysroot for cross-compilation
> > are located in /usr/aarch64-linux-gnu,
> > /usr/arm-linux-gnueabi, /usr/arm-linux-gnueabihf,
> > /usr/i686-linux-gnu/ etc. but I do not know if it
> > is the same across distros.
>
> Right. If I remember the glibc/binutils/gcc bootstrap dance, I thought
> gcc was configured with a known path to a particular version of glibc.
> So a cross toolchain knew where to look for its cross libc.
>
> Clang doesn't have such configure time step; it can cross compile
> easily with one binary, but cross linking a working executable is
> still a PITA due to not knowing which cross libc to link against.  I'm
> not sure whether we need to improve Clang's logic when cross compiling
> to look in "sane default" paths for a cross libc, or if we should just
> add some flag when cross compiling with clang in Kbuild (such as
> --sysroot) in order for CONFIG_CC_CAN_LINK to work as expected.
> Fangrui probably has a good opinion about this.
>
> Zig (the compiler, but also the language name) can do this quite
> nicely. I'm envious.
> https://twitter.com/andy_kelley/status/1241409388532948992?lang=en
> https://www.youtube.com/watch?v=pq1XqP4-qOo
>
> But this is also somewhat orthogonal to the goal of "infer
> CROSS_COMPILE (or really, --target=) from ARCH (or really, SRCARCH)" I
> think.  It's still interesting for us all to discuss on-list though.
>
> >
> >
> >
> >
> >
> > [4] What is the best target if we hard-code it?
> >
> > Currently, we require the correct CROSS_COMPILE
> > is provided by users.
> >
> > The target might impact the performance
> > or the ABI.
> > It was difficult for me to define
> > which one is better than another.
> >
> > For example for ARCH=arm, which is better
> > --target=arm-linux-gnueabi or
> > --target=arm-lnux-gnueabihf or
> > something we don't care about?
>
> Yes, this is a case I was interested in.  I've used either
> interchangeably without issue for years.  That's not to say we get the
> same binary image with either.
>
> I get the same .config for the defconfig target with either.
>
> If I zero out KBUILD_BUILD_TIMESTAMP and the build number, I still get
> different sha1sums.  Though that assumes clang, lld, and kbuild are
> all deterministic, which I also haven't spent time to verify.
> --
> Thanks,
> ~Nick Desaulniers
>
> --
> 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/CAKwvOdmufESjYQVZmaPdTXgZO5Ogz%2BOppVSUGAn6BZaC%2BYZhbw%40mail.gmail.com.



--
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-08 18:04     ` Nick Desaulniers
@ 2021-07-09  8:07       ` Arnd Bergmann
  2021-07-14 18:09         ` Nick Desaulniers
  0 siblings, 1 reply; 17+ messages in thread
From: Arnd Bergmann @ 2021-07-09  8:07 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Christoph Hellwig, Masahiro Yamada, Miguel Ojeda, Fangrui Song,
	Michal Marek, Linux Kernel Mailing List,
	Linux Kbuild mailing list, clang-built-linux, Linus Torvalds

On Thu, Jul 8, 2021 at 8:04 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:

> > /usr/bin/powerpc64-linux-gnu-gcc-5.2.0
> > /usr/bin/powerpc64-linux-gnu-gcc -> powerpc64-linux-gnu-gcc-5.2.0
> > /usr/local/bin/ppc64le-linux-gcc-9
> > ~/bin/powerpc/powerpc-linux-unknown-gcc-12.0.20210708.experimental
> >
> > all of these should be able to cross-build any powerpc kernel, but
> > there is no obvious first choice (highest version, first in path,
> > ordered list of target triples, ...). I tried coming up with a heuristic
> > to pick a reasonable toolchain, but at some point gave up because
> > I failed to express that in a readable bash or Makefile syntax.
>
> Right; foremost in my mind was arm-linux-gnueabi-gcc vs
> arm-linux-gnueabihf-gcc.  That's not even to mention the versioned
> suffixes.
>
> In terms of multiversion support; this series doesn't regress doing
> things the hard/verbose way.  But I think for most users we can have a
> simpler common case; folks can play with their $PATH or focus on more
> hermetic builds if they want this new feature (CROSS_COMPILE
> inference) AND support for multiple versions of the same toolchain.

Fair enough. So how something like this:

powerpc-targets := powerpc32 powerpc64 powerpc32le \
        powerpc32be powerpc64le powerpc64be ppc64le ppc64be
arm-targets := arm-linux-gnueabi arm-linux-gnueabihf
x86-targets := x86_64 i386 i686
x86_64-targets := x86
i386-targets := i686 x86 x86_64
parisc-targets := hppa64 hppa
...

CROSS_COMPILE ?= `find-toolchain $(ARCH) $($(ARCH)-targets)`

where find-toolchain just finds the first working toolchain based, looking
for $(target)-linux-gcc $(target)-gcc $(target)-unknown-linux-gcc etc
in $(PATH) but ignoring the versions?

What I had actually planned was a set of helpers that allow you to
do this in multiple steps:

- if $(objtree)/scripts/cross/bin/gcc (or something else we pick)
  exists and CROSS_COMPILE is not set, set CROSS_COMPILE
  to $(objtree)/scripts/cross/bin/ in the Makefile
- add script to enumerate the installed toolchains
- add a second script to symlink one of those toolchains to
  $(objtree)/scripts/cross/bin
- add a third script to download a cross-toolchain from kernel.org
  for $(ARCH) and install it to one of the locations that the first
  script looks for (/opt/cross/, $(HOME)/cross/, $(objtree)scripts/cross/)

        Arnd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-09  8:07       ` Arnd Bergmann
@ 2021-07-14 18:09         ` Nick Desaulniers
  2021-07-14 20:18           ` Arnd Bergmann
  0 siblings, 1 reply; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-14 18:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Christoph Hellwig, Masahiro Yamada, Miguel Ojeda, Fangrui Song,
	Michal Marek, Linux Kernel Mailing List,
	Linux Kbuild mailing list, clang-built-linux, Linus Torvalds

On Fri, Jul 9, 2021 at 1:07 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Jul 8, 2021 at 8:04 PM 'Nick Desaulniers' via Clang Built
> Linux <clang-built-linux@googlegroups.com> wrote:
>
> > > /usr/bin/powerpc64-linux-gnu-gcc-5.2.0
> > > /usr/bin/powerpc64-linux-gnu-gcc -> powerpc64-linux-gnu-gcc-5.2.0
> > > /usr/local/bin/ppc64le-linux-gcc-9
> > > ~/bin/powerpc/powerpc-linux-unknown-gcc-12.0.20210708.experimental
> > >
> > > all of these should be able to cross-build any powerpc kernel, but
> > > there is no obvious first choice (highest version, first in path,
> > > ordered list of target triples, ...). I tried coming up with a heuristic
> > > to pick a reasonable toolchain, but at some point gave up because
> > > I failed to express that in a readable bash or Makefile syntax.
> >
> > Right; foremost in my mind was arm-linux-gnueabi-gcc vs
> > arm-linux-gnueabihf-gcc.  That's not even to mention the versioned
> > suffixes.
> >
> > In terms of multiversion support; this series doesn't regress doing
> > things the hard/verbose way.  But I think for most users we can have a
> > simpler common case; folks can play with their $PATH or focus on more
> > hermetic builds if they want this new feature (CROSS_COMPILE
> > inference) AND support for multiple versions of the same toolchain.
>
> Fair enough. So how something like this:
>
> powerpc-targets := powerpc32 powerpc64 powerpc32le \
>         powerpc32be powerpc64le powerpc64be ppc64le ppc64be
> arm-targets := arm-linux-gnueabi arm-linux-gnueabihf
> x86-targets := x86_64 i386 i686
> x86_64-targets := x86
> i386-targets := i686 x86 x86_64
> parisc-targets := hppa64 hppa
> ...
>
> CROSS_COMPILE ?= `find-toolchain $(ARCH) $($(ARCH)-targets)`
>
> where find-toolchain just finds the first working toolchain based, looking
> for $(target)-linux-gcc $(target)-gcc $(target)-unknown-linux-gcc etc
> in $(PATH) but ignoring the versions?

Sure, debian doesn't even package different versions of the cross GCC
packages AFAIK; no idea about other distros.  Though the user may have
built from source, or have multiple versions fetched from tarballs.

I think we can simplify the common case of "I just wan't to cross
compile, I don't necessarily care about an older compiler version
co-installed with a newer one." ("and if I did, I could still use
CROSS_COMPILE the verbose way").

> What I had actually planned was a set of helpers that allow you to
> do this in multiple steps:
>
> - if $(objtree)/scripts/cross/bin/gcc (or something else we pick)
>   exists and CROSS_COMPILE is not set, set CROSS_COMPILE
>   to $(objtree)/scripts/cross/bin/ in the Makefile
> - add script to enumerate the installed toolchains
> - add a second script to symlink one of those toolchains to
>   $(objtree)/scripts/cross/bin

(and check the symlink isn't broken should the user uninstall a
toolchain, or have their distro update their toolchain version)

> - add a third script to download a cross-toolchain from kernel.org
>   for $(ARCH) and install it to one of the locations that the first
>   script looks for (/opt/cross/, $(HOME)/cross/, $(objtree)scripts/cross/)

Would the user be prompted for the download? So during
`defconfig`/configuration we could prompt and say "it looks like
you're cross compiling without setting CROSS_COMPILE, would you like
me to fetch a cross compiler for you?"

Seems reasonable, when cross compiling with GCC.
-- 
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-14 18:09         ` Nick Desaulniers
@ 2021-07-14 20:18           ` Arnd Bergmann
  0 siblings, 0 replies; 17+ messages in thread
From: Arnd Bergmann @ 2021-07-14 20:18 UTC (permalink / raw)
  To: Nick Desaulniers
  Cc: Christoph Hellwig, Masahiro Yamada, Miguel Ojeda, Fangrui Song,
	Michal Marek, Linux Kernel Mailing List,
	Linux Kbuild mailing list, clang-built-linux, Linus Torvalds

On Wed, Jul 14, 2021 at 8:09 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> On Fri, Jul 9, 2021 at 1:07 AM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Thu, Jul 8, 2021 at 8:04 PM 'Nick Desaulniers' via Clang Built
> > Linux <clang-built-linux@googlegroups.com> wrote:
> >
> > > > /usr/bin/powerpc64-linux-gnu-gcc-5.2.0
> > > > /usr/bin/powerpc64-linux-gnu-gcc -> powerpc64-linux-gnu-gcc-5.2.0
> > > > /usr/local/bin/ppc64le-linux-gcc-9
> > > > ~/bin/powerpc/powerpc-linux-unknown-gcc-12.0.20210708.experimental
> > > >
> > > > all of these should be able to cross-build any powerpc kernel, but
> > > > there is no obvious first choice (highest version, first in path,
> > > > ordered list of target triples, ...). I tried coming up with a heuristic
> > > > to pick a reasonable toolchain, but at some point gave up because
> > > > I failed to express that in a readable bash or Makefile syntax.
> > >
> > > Right; foremost in my mind was arm-linux-gnueabi-gcc vs
> > > arm-linux-gnueabihf-gcc.  That's not even to mention the versioned
> > > suffixes.
> > >
> > > In terms of multiversion support; this series doesn't regress doing
> > > things the hard/verbose way.  But I think for most users we can have a
> > > simpler common case; folks can play with their $PATH or focus on more
> > > hermetic builds if they want this new feature (CROSS_COMPILE
> > > inference) AND support for multiple versions of the same toolchain.
> >
> > Fair enough. So how something like this:
> >
> > powerpc-targets := powerpc32 powerpc64 powerpc32le \
> >         powerpc32be powerpc64le powerpc64be ppc64le ppc64be
> > arm-targets := arm-linux-gnueabi arm-linux-gnueabihf
> > x86-targets := x86_64 i386 i686
> > x86_64-targets := x86
> > i386-targets := i686 x86 x86_64
> > parisc-targets := hppa64 hppa
> > ...
> >
> > CROSS_COMPILE ?= `find-toolchain $(ARCH) $($(ARCH)-targets)`
> >
> > where find-toolchain just finds the first working toolchain based, looking
> > for $(target)-linux-gcc $(target)-gcc $(target)-unknown-linux-gcc etc
> > in $(PATH) but ignoring the versions?
>
> Sure, debian doesn't even package different versions of the cross GCC
> packages AFAIK; no idea about other distros.  Though the user may have
> built from source, or have multiple versions fetched from tarballs.

I have an Ubuntu installation with gcc-9, gcc-10 and gcc-11 cross
toolchains installed from through apt, but none that is just 'gcc'
without a version as the ones I built myself are.

> I think we can simplify the common case of "I just want to cross
> compile, I don't necessarily care about an older compiler version
> co-installed with a newer one." ("and if I did, I could still use
> CROSS_COMPILE the verbose way").

Right, in my example above one would still have to set CC=
since the detected target triple has no $(CROSS_COMPILE)gcc,
only the versioned ones.

Setting up the symlinks however should get you there.

> > What I had actually planned was a set of helpers that allow you to
> > do this in multiple steps:
> >
> > - if $(objtree)/scripts/cross/bin/gcc (or something else we pick)
> >   exists and CROSS_COMPILE is not set, set CROSS_COMPILE
> >   to $(objtree)/scripts/cross/bin/ in the Makefile
> > - add script to enumerate the installed toolchains
> > - add a second script to symlink one of those toolchains to
> >   $(objtree)/scripts/cross/bin
>
> (and check the symlink isn't broken should the user uninstall a
> toolchain, or have their distro update their toolchain version)

There are lots of options for the policy here. My preference would
be to just pick the one from the symlink before any other, and then
have a step 'make config' family of commands that checks that
the selected toolchain actually produces object code for the selected
architecture.

> > - add a third script to download a cross-toolchain from kernel.org
> >   for $(ARCH) and install it to one of the locations that the first
> >   script looks for (/opt/cross/, $(HOME)/cross/, $(objtree)scripts/cross/)
>
> Would the user be prompted for the download? So during
> `defconfig`/configuration we could prompt and say "it looks like
> you're cross compiling without setting CROSS_COMPILE, would you like
> me to fetch a cross compiler for you?"
>
> Seems reasonable, when cross compiling with GCC.

I don't think we want interactive commands in the build system other
than 'make config', but it would be reasonable to print something like

"no compiler found", "selected compiler ${CC} does not match architecture
${ARCH}", or "selected compiler ${CC} does not work", followed by a
list of suggested commands to configure or download a different toolchain.

       Arnd

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1
  2021-07-07 22:43 [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1 Nick Desaulniers
                   ` (2 preceding siblings ...)
  2021-07-08  5:49 ` [PATCH 0/2] infer CROSS_COMPILE from ARCH " Christoph Hellwig
@ 2021-07-19 21:10 ` Nick Desaulniers
  3 siblings, 0 replies; 17+ messages in thread
From: Nick Desaulniers @ 2021-07-19 21:10 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Miguel Ojeda, Fangrui Song, Michal Marek, Arnd Bergmann,
	linux-kernel, linux-kbuild, clang-built-linux

Masahiro,
Do you have further thoughts on this series?


On Wed, Jul 7, 2021 at 3:43 PM Nick Desaulniers <ndesaulniers@google.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 ARCH.
>
> Instead, let's infer it from ARCH, and move some flag handling into a
> new file included from the top level Makefile.
>
> Nick Desaulniers (2):
>   Makefile: move initial clang flag handling into scripts/Makefile.clang
>   Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1
>
>  Documentation/kbuild/llvm.rst |  5 ++++
>  MAINTAINERS                   |  1 +
>  Makefile                      | 15 +----------
>  scripts/Makefile.clang        | 48 +++++++++++++++++++++++++++++++++++
>  4 files changed, 55 insertions(+), 14 deletions(-)
>  create mode 100644 scripts/Makefile.clang
>
>
> base-commit: a0e781a2a35a8dd4e6a38571998d59c6b0e32cd8
> --
> 2.32.0.93.g670b81a890-goog
>


--
Thanks,
~Nick Desaulniers

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2021-07-19 21:38 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-07 22:43 [PATCH 0/2] infer CROSS_COMPILE from ARCH for LLVM=1 LLVM_IAS=1 Nick Desaulniers
2021-07-07 22:43 ` [PATCH 1/2] Makefile: move initial clang flag handling into scripts/Makefile.clang Nick Desaulniers
2021-07-07 22:43 ` [PATCH 2/2] Makefile: drop CROSS_COMPILE for LLVM=1 LLVM_IAS=1 Nick Desaulniers
2021-07-08  8:08   ` Geert Uytterhoeven
2021-07-08  8:44     ` Masahiro Yamada
2021-07-08 10:21   ` Masahiro Yamada
2021-07-08 11:44     ` Arnd Bergmann
2021-07-08 19:06       ` Nick Desaulniers
2021-07-08 19:02     ` Nick Desaulniers
2021-07-08 19:47       ` Masahiro Yamada
2021-07-08  5:49 ` [PATCH 0/2] infer CROSS_COMPILE from ARCH " Christoph Hellwig
2021-07-08  7:27   ` Arnd Bergmann
2021-07-08 18:04     ` Nick Desaulniers
2021-07-09  8:07       ` Arnd Bergmann
2021-07-14 18:09         ` Nick Desaulniers
2021-07-14 20:18           ` Arnd Bergmann
2021-07-19 21:10 ` Nick Desaulniers

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.