Received-SPF: pass (google.com: domain of linux-kernel+bounces-124403-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Valentin Obst <kernel@valentinobst.de>
Date: Fri, 29 Mar 2024 11:49:43 +0100
Subject: [PATCH] selftests: default to host arch for LLVM builds
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de>
To: Shuah Khan <shuah@kernel.org>
Cc: Anders Roxell <anders.roxell@linaro.org>, 
 Benjamin Poirier <bpoirier@nvidia.com>, 
 Guillaume Tucker <guillaume.tucker@collabora.com>, 
 John Hubbard <jhubbard@nvidia.com>, 
 Marcos Paulo de Souza <mpdesouza@suse.com>, Mark Brown <broonie@kernel.org>, 
 Nathan Chancellor <nathan@kernel.org>, Sasha Levin <sashal@kernel.org>, 
 linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, 
 Valentin Obst <kernel@valentinobst.de>
UI-OutboundReport: notjunk:1;M01:P0:AgfD508H+Fo=;siKZkViJ4T0o9Tfokk2cE9yZ9wx
 chgr+6sz5Ik5m9a+AMHYkZokSrXM7/OmLAh3LZ+UtUvTyqB7DyqIQNP5IccozyWUXB9VsCIWn
 eNIV4XucR0M30OEDWvvDHL0oc0CrBm79VALsjGAIFR4vF1ulKg1rGmVy+D6hz6bIgxtXu537B
 usxu/Aim7TwZC2h8Tgo3kX3V/vLfl34Fox+w2p1HmfPRKD5XKRssPo73MUBjg3+Jk/4xvLmlm
 B1pRExnGFtCc7EW9MACRhnXgHlUC0RskXZqbb/+6cWz6m7/JhsXl1Z09eanhnQfiymctIvXLG
 v20dq4Ta+h2X5sE32c/ru1TshJRlzlUE8wsA1Wq6Agf4TTNtIni9HKeI5ZBtkiZQ73Kk/IDqz
 V0y3yCs0yXKrE9bKgi7W6/vh3b+0vF3Bq6Ej/3H/OnsYrC6OPYkFBsrC6kbNvR9J6GwUDq4Te
 929E1odb1SlTmSM+LubVNpX//h8n+i7LbtjjDZmFmC2AZFZO3Sud8CCVa5tQBT7MIY42Q+s+A
 F7UYyO47pDPXV6UQXx9J2jGJ4cPoXmw2IdmBYENcPuB05llYzde+EvvcUDwS3fqcT0YDPn0sx
 tTiEJmCekeko44kYruE9RH3qQ8cE+IiOeaUCtIJKyg9PTtUqCEr0vgxs4wW+Og+SLZ+Zzps7A
 R6KxTVeMralKj2GsuJf4LMhJD16P2GRP5tqszpdZeSomxg6p9vcR0YHHjlJ18PsoRAtREStHd
 HiZyILw1s1SemEGKLJQg2E0z4tpYB2zpE1EGPWmsbGODlSRjpE3vyA=

Align the behavior for gcc and clang builds by interpreting unset
`ARCH` and `CROSS_COMPILE` variables in `LLVM` builds as a sign that the
user wants to build for the host architecture.

This patch preserves the properties that setting the `ARCH` variable to an
unknown value will trigger an error that complains about insufficient
information, and that a set `CROSS_COMPILE` variable will override the
target triple that is determined based on presence/absence of `ARCH`.

When compiling with clang, i.e., `LLVM` is set, an unset `ARCH` variable i=
n
combination with an unset `CROSS_COMPILE` variable, i.e., compiling for
the host architecture, leads to compilation failures since `lib.mk` can
not determine the clang target triple. In this case, the following error
message is displayed for each subsystem that does not set `ARCH` in its
own Makefile before including `lib.mk` (lines wrapped at 75 chrs):

  make[1]: Entering directory '/mnt/build/linux/tools/testing/selftests/
   sysctl'
  ../lib.mk:33: *** Specify CROSS_COMPILE or add '--target=3D' option to
   lib.mk.  Stop.
  make[1]: Leaving directory '/mnt/build/linux/tools/testing/selftests/
   sysctl'

In the same scenario a gcc build would default to the host architecture,
i.e., it would use plain `gcc`.

Fixes: 795285ef2425 ("selftests: Fix clang cross compilation")
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Valentin Obst <kernel@valentinobst.de>
=2D--
I am not entirely sure whether this behavior is in fact known and intended
and whether the way to obtain the host target triple is sufficiently
general. The flag was introduced in llvm-8 with [1], it will be an error i=
n
older clang versions.

The target triple you get with `-print-target-triple` may not be the
same that you would get when explicitly setting ARCH to you host
architecture. For example on my x86_64 system it get
`x86_64-pc-linux-gnu` instead of `x86_64-linux-gnu`, similar deviations
were observed when testing other clang binaries on compiler-explorer,
e.g., [2].

An alternative could be to simply do:

      ARCH ?=3D $(shell uname -m)

before using it to select the target. Possibly with some post processing,
but at that point we would likely be replicating `scripts/subarch.include`=
.
This is what some subsystem Makefiles do before including `lib.mk`. This
change might make it possible to remove the explicit setting of `ARCH` fro=
m
the few subsystem Makefiles that do it.

[1]: https://reviews.llvm.org/D50755
[2]: https://godbolt.org/z/r7Gn9bvv1

Changes in v1:
- Shortened commit message.
- Link to RFC: https://lore.kernel.org/r/20240303-selftests-libmk-llvm-rfc=
-v1-1-9ab53e365e31@valentinobst.de
=2D--
 tools/testing/selftests/lib.mk | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.=
mk
index da2cade3bab0..8ae203d8ed7f 100644
=2D-- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -7,6 +7,8 @@ else ifneq ($(filter -%,$(LLVM)),)
 LLVM_SUFFIX :=3D $(LLVM)
 endif

+CLANG :=3D $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
+
 CLANG_TARGET_FLAGS_arm          :=3D arm-linux-gnueabi
 CLANG_TARGET_FLAGS_arm64        :=3D aarch64-linux-gnu
 CLANG_TARGET_FLAGS_hexagon      :=3D hexagon-linux-musl
@@ -18,7 +20,13 @@ CLANG_TARGET_FLAGS_riscv        :=3D riscv64-linux-gnu
 CLANG_TARGET_FLAGS_s390         :=3D s390x-linux-gnu
 CLANG_TARGET_FLAGS_x86          :=3D x86_64-linux-gnu
 CLANG_TARGET_FLAGS_x86_64       :=3D x86_64-linux-gnu
-CLANG_TARGET_FLAGS              :=3D $(CLANG_TARGET_FLAGS_$(ARCH))
+
+# Default to host architecture if ARCH is not explicitly given.
+ifeq ($(ARCH),)
+CLANG_TARGET_FLAGS :=3D $(shell $(CLANG) -print-target-triple)
+else
+CLANG_TARGET_FLAGS :=3D $(CLANG_TARGET_FLAGS_$(ARCH))
+endif

 ifeq ($(CROSS_COMPILE),)
 ifeq ($(CLANG_TARGET_FLAGS),)
@@ -30,7 +38,7 @@ else
 CLANG_FLAGS     +=3D --target=3D$(notdir $(CROSS_COMPILE:%-=3D%))
 endif # CROSS_COMPILE

-CC :=3D $(LLVM_PREFIX)clang$(LLVM_SUFFIX) $(CLANG_FLAGS) -fintegrated-as
+CC :=3D $(CLANG) $(CLANG_FLAGS) -fintegrated-as
 else
 CC :=3D $(CROSS_COMPILE)gcc
 endif # LLVM

=2D--
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240303-selftests-libmk-llvm-rfc-5fe3cfa9f094

Best regards,
=2D-
Valentin Obst <kernel@valentinobst.de>