Currently, even if we are using clang as a C compiler, we still use
GNU binutils. This patch adds new option "llvm" that allows to use
linker, objcopy and all other tools from LLVM project. As LLVM tools
use different approach for cross-compilation, we don't need
CROSS_COMPILE prefix in this case.

Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
 config/GNUCommon.mk | 16 ++++++++++++++++
 config/Linux.mk     |  4 ++++
 config/StdGNU.mk    | 18 +-----------------
 config/llvm.mk      | 17 +++++++++++++++++
 4 files changed, 38 insertions(+), 17 deletions(-)
 create mode 100644 config/GNUCommon.mk
 create mode 100644 config/llvm.mk

diff --git a/config/GNUCommon.mk b/config/GNUCommon.mk
new file mode 100644
index 0000000000..71c2303166
--- /dev/null
+++ b/config/GNUCommon.mk
@@ -0,0 +1,16 @@
+# Allow git to be wrappered in the environment
+GIT        ?= git
+
+INSTALL      = install
+INSTALL_DIR  = $(INSTALL) -d -m0755 -p
+INSTALL_DATA = $(INSTALL) -m0644 -p
+INSTALL_PROG = $(INSTALL) -m0755 -p
+
+BOOT_DIR ?= /boot
+DEBUG_DIR ?= /usr/lib/debug
+
+SOCKET_LIBS =
+UTIL_LIBS = -lutil
+
+SONAME_LDFLAG = -soname
+SHLIB_LDFLAGS = -shared
diff --git a/config/Linux.mk b/config/Linux.mk
index 2a84b6b0f3..6f4dc865a2 100644
--- a/config/Linux.mk
+++ b/config/Linux.mk
@@ -1,3 +1,7 @@
+ifeq ($(llvm),y)
+include $(XEN_ROOT)/config/llvm.mk
+else
 include $(XEN_ROOT)/config/StdGNU.mk
+endif
 
 SYSCONFIG_DIR = $(CONFIG_DIR)/$(CONFIG_LEAF_DIR)
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index aaa0d007f7..d723bc274e 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -19,20 +19,4 @@ OBJCOPY    = $(CROSS_COMPILE)objcopy
 OBJDUMP    = $(CROSS_COMPILE)objdump
 SIZEUTIL   = $(CROSS_COMPILE)size
 
-# Allow git to be wrappered in the environment
-GIT        ?= git
-
-INSTALL      = install
-INSTALL_DIR  = $(INSTALL) -d -m0755 -p
-INSTALL_DATA = $(INSTALL) -m0644 -p
-INSTALL_PROG = $(INSTALL) -m0755 -p
-
-BOOT_DIR ?= /boot
-DEBUG_DIR ?= /usr/lib/debug
-
-SOCKET_LIBS =
-UTIL_LIBS = -lutil
-
-SONAME_LDFLAG = -soname
-SHLIB_LDFLAGS = -shared
-
+include $(XEN_ROOT)/config/GNUCommon.mk
diff --git a/config/llvm.mk b/config/llvm.mk
new file mode 100644
index 0000000000..e474428286
--- /dev/null
+++ b/config/llvm.mk
@@ -0,0 +1,17 @@
+AS         = llvm-as
+LD         = ld.lld
+CC         = clang
+CXX        = clang++
+LD_LTO     = llvm-lto
+CPP        = $(CC) -E
+ADDR2LINE  = llvm-addr2line
+AR         = llvm-ar
+RANLIB     = llvm-ranlib
+NM         = llvm-nm
+STRIP      = llvm-strip
+OBJCOPY    = llvm-objcopy
+OBJDUMP    = llvm-objdump
+SIZEUTIL   = llvm-size
+
+include $(XEN_ROOT)/config/GNUCommon.mk
+
-- 
2.47.0

On 29.11.2024 02:49, Volodymyr Babchuk wrote:
> Currently, even if we are using clang as a C compiler, we still use
> GNU binutils. This patch adds new option "llvm" that allows to use
> linker, objcopy and all other tools from LLVM project. As LLVM tools
> use different approach for cross-compilation, we don't need
> CROSS_COMPILE prefix in this case.

This new option is meant to control both toolstack and hypervisor builds?
As to the latter, I assume you're aware we're trying to move away from
this kind of command line control of the build.

How is this intended to interact with the existing $(clang) that we have?
In the cover letter you appear to only care about the clang=y llvm=y case,
while ...

> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -19,20 +19,4 @@ OBJCOPY    = $(CROSS_COMPILE)objcopy
>  OBJDUMP    = $(CROSS_COMPILE)objdump
>  SIZEUTIL   = $(CROSS_COMPILE)size

... even up from here there are uses of $(clang).

Also please Cc Anthony on build system changes.

Jan

On Fri, Nov 29, 2024 at 08:57:47AM +0100, Jan Beulich wrote:
> On 29.11.2024 02:49, Volodymyr Babchuk wrote:
> > Currently, even if we are using clang as a C compiler, we still use
> > GNU binutils. This patch adds new option "llvm" that allows to use
> > linker, objcopy and all other tools from LLVM project. As LLVM tools
> > use different approach for cross-compilation, we don't need
> > CROSS_COMPILE prefix in this case.

It might be worth explaining what this different approach is ;-). My
guess is that you ask llvm/clang to build for a specific arch, via
XEN_TARGET_ARCH=riscv64, and llvm doesn't need different binaries will
just do what is needed, right? (with -march I guess).

> This new option is meant to control both toolstack and hypervisor builds?
> As to the latter, I assume you're aware we're trying to move away from
> this kind of command line control of the build.

Having "clang=y" is a bit useless when one can do "CC=clang" and let
the build system figure out what CC is. That's at least true for the
build system under "xen/".

But if one want to use the whole LLVM toolchain, it as to write a lot
more. To build Xen (just the hypervisor) with it, one would need to run:

make CC=clang CXX=clang++ AS=llvm-as LD=ld.lld LD_LTO=llvm-lto \
    ADDR2LINE=llvm-addr2line AR=llvm-ar RANLIB=llvm-ranlib NM=llvm-nm \
    STRIP=llvm-strip OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump \
    SIZEUTIL=llvm-size

So while it's possible, maybe introducing "llvm" or "LLVM" to switch
toolchain might be ok, to help. (Just because Linux did just that
recently:
    https://www.kernel.org/doc/html/latest/kbuild/llvm.html#the-llvm-argument
)

Beyond switching toolchain, I don't think $(llvm) or $(clang) should be
used in the build system, and instead rely on autodetection for
arguments. (There's already $(CONFIG_CC_IS_CLANG) and
$(CONFIG_LD_IS_LLVM) in the hypervisor's build system, via Kconfig)

At least for the hypervisor. For the toolstack, we should probably deal
with toolchain in ./configure.

Thanks,

-- 

Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech