| Message ID | 20241129014850.2852844-3-volodymyr_babchuk@epam.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | aarch64, common: improve clang and llvm support | expand |
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,
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 +
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