Provide -target and -march explicitly when building with clang. This
makes cross-compilation much easier, because clang accept this
parameters regardless of host platform. Basically,
make XEN_TARGET_ARCH=arm64 clang=y llvm=y
will behave in the same way if building Xen on x86, or on arm64 or on
any other platform.
-march is required because with default value, clang will not
recognize EL2 registers.
Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
---
config/arm64.mk | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/config/arm64.mk b/config/arm64.mk
index c4662f67d0..97eb9a82e7 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX :=
CFLAGS += #-marm -march= -mcpu= etc
+ifeq ($(clang),y)
+CFLAGS += -target aarch64 -march=armv8-a
+endif
+
# Use only if calling $(LD) directly.
LDFLAGS_DIRECT += -EL
--
2.47.0Hi Volodymyr, On 29/11/2024 01:49, Volodymyr Babchuk wrote: > Provide -target and -march explicitly when building with clang. This > makes cross-compilation much easier, because clang accept this > parameters regardless of host platform. Basically, > > make XEN_TARGET_ARCH=arm64 clang=y llvm=y > > will behave in the same way if building Xen on x86, or on arm64 or on > any other platform. > > -march is required because with default value, clang will not > recognize EL2 registers. Any chance this is happening because you are using "-target aarch64" rather than e.g. "arch64-arm-none-eabi"? > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > config/arm64.mk | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/config/arm64.mk b/config/arm64.mk > index c4662f67d0..97eb9a82e7 100644 > --- a/config/arm64.mk > +++ b/config/arm64.mk > @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := > > CFLAGS += #-marm -march= -mcpu= etc > > +ifeq ($(clang),y) > +CFLAGS += -target aarch64 -march=armv8-a AFAIU, -target is the triplet similar to what one would set CROSS_COMPILE. If you don't specify some values, then it will assume the compiler defaults. I am not sure this is a good idea as this could change between compilers. So should we set the triplet properly (e.g. arch64-arm-none-eabi) or maybe let the user specify it via CROSS_COMPILE? Regarding -march=armv8-a, if you want to keep it, then I think it should be outside of the 'if' because this could also apply for GCC. Cheers, -- Julien Grall
On 29.11.2024 02:49, Volodymyr Babchuk wrote: > Provide -target and -march explicitly when building with clang. This > makes cross-compilation much easier, because clang accept this > parameters regardless of host platform. Basically, > > make XEN_TARGET_ARCH=arm64 clang=y llvm=y > > will behave in the same way if building Xen on x86, or on arm64 or on > any other platform. > > -march is required because with default value, clang will not > recognize EL2 registers. > > Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> > --- > config/arm64.mk | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/config/arm64.mk b/config/arm64.mk > index c4662f67d0..97eb9a82e7 100644 > --- a/config/arm64.mk > +++ b/config/arm64.mk > @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := > > CFLAGS += #-marm -march= -mcpu= etc > > +ifeq ($(clang),y) > +CFLAGS += -target aarch64 -march=armv8-a > +endif Why is this dependent on (just?) $(clang), not (also?) $(llvm)? Also this affects both toolstack builds and hypervisor. Is applying -march like this actually appropriate for the toolstack? Jan
Hi Jan, Jan Beulich <jbeulich@suse.com> writes: > On 29.11.2024 02:49, Volodymyr Babchuk wrote: >> Provide -target and -march explicitly when building with clang. This >> makes cross-compilation much easier, because clang accept this >> parameters regardless of host platform. Basically, >> >> make XEN_TARGET_ARCH=arm64 clang=y llvm=y >> >> will behave in the same way if building Xen on x86, or on arm64 or on >> any other platform. >> >> -march is required because with default value, clang will not >> recognize EL2 registers. >> >> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> >> --- >> config/arm64.mk | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/config/arm64.mk b/config/arm64.mk >> index c4662f67d0..97eb9a82e7 100644 >> --- a/config/arm64.mk >> +++ b/config/arm64.mk >> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >> >> CFLAGS += #-marm -march= -mcpu= etc >> >> +ifeq ($(clang),y) >> +CFLAGS += -target aarch64 -march=armv8-a >> +endif > > Why is this dependent on (just?) $(clang), not (also?) $(llvm)? Because this parameter is handled by clang only. There is no harm in providing it explicitly. When building on arm64, value of this parameter will match the default value for the platform. When building on x86, we need to tell clang that it should generate arm64 code anyways. There is no reason in trying to make ARM build with x86 instruction set. > Also > this affects both toolstack builds and hypervisor. Is applying -march > like this actually appropriate for the toolstack? This is a good question. I can't see why this can't be appropriate for toolstack. I.e. what bad can happen when building the toolstack. -- WBR, Volodymyr
Hi, On 29/11/2024 22:12, Volodymyr Babchuk wrote: > > Hi Jan, > > Jan Beulich <jbeulich@suse.com> writes: > >> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>> Provide -target and -march explicitly when building with clang. This >>> makes cross-compilation much easier, because clang accept this >>> parameters regardless of host platform. Basically, >>> >>> make XEN_TARGET_ARCH=arm64 clang=y llvm=y >>> >>> will behave in the same way if building Xen on x86, or on arm64 or on >>> any other platform. >>> >>> -march is required because with default value, clang will not >>> recognize EL2 registers. >>> >>> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> >>> --- >>> config/arm64.mk | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/config/arm64.mk b/config/arm64.mk >>> index c4662f67d0..97eb9a82e7 100644 >>> --- a/config/arm64.mk >>> +++ b/config/arm64.mk >>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >>> >>> CFLAGS += #-marm -march= -mcpu= etc >>> >>> +ifeq ($(clang),y) >>> +CFLAGS += -target aarch64 -march=armv8-a >>> +endif >> >> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? > > Because this parameter is handled by clang only. There is no harm in > providing it explicitly. When building on arm64, value of this parameter > will match the default value for the platform. When building on x86, we > need to tell clang that it should generate arm64 code anyways. There is > no reason in trying to make ARM build with x86 instruction set. > >> Also >> this affects both toolstack builds and hypervisor. Is applying -march >> like this actually appropriate for the toolstack? > > This is a good question. I can't see why this can't be appropriate for > toolstack. I.e. what bad can happen when building the toolstack. In the future, we may want to build the tools for Armv8-M. So I think the -march should also applies for the toolstack. Cheers, -- Julien Grall
On 30.11.2024 18:15, Julien Grall wrote: > On 29/11/2024 22:12, Volodymyr Babchuk wrote: >> Jan Beulich <jbeulich@suse.com> writes: >>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>> --- a/config/arm64.mk >>>> +++ b/config/arm64.mk >>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >>>> >>>> CFLAGS += #-marm -march= -mcpu= etc >>>> >>>> +ifeq ($(clang),y) >>>> +CFLAGS += -target aarch64 -march=armv8-a >>>> +endif >>> >>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >> >> Because this parameter is handled by clang only. There is no harm in >> providing it explicitly. When building on arm64, value of this parameter >> will match the default value for the platform. When building on x86, we >> need to tell clang that it should generate arm64 code anyways. There is >> no reason in trying to make ARM build with x86 instruction set. >> >>> Also >>> this affects both toolstack builds and hypervisor. Is applying -march >>> like this actually appropriate for the toolstack? >> >> This is a good question. I can't see why this can't be appropriate for >> toolstack. I.e. what bad can happen when building the toolstack. > > In the future, we may want to build the tools for Armv8-M. So I think > the -march should also applies for the toolstack. Perhaps I don't know enough of the Arm world, but: Wouldn't it be possible to build a tool stack suitable for a wide range for Arm64 flavors, while requiring more targeted hypervisor binaries? Jan
Hi Jan, On 02/12/2024 07:52, Jan Beulich wrote: > On 30.11.2024 18:15, Julien Grall wrote: >> On 29/11/2024 22:12, Volodymyr Babchuk wrote: >>> Jan Beulich <jbeulich@suse.com> writes: >>>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>>> --- a/config/arm64.mk >>>>> +++ b/config/arm64.mk >>>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >>>>> >>>>> CFLAGS += #-marm -march= -mcpu= etc >>>>> >>>>> +ifeq ($(clang),y) >>>>> +CFLAGS += -target aarch64 -march=armv8-a >>>>> +endif >>>> >>>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >>> >>> Because this parameter is handled by clang only. There is no harm in >>> providing it explicitly. When building on arm64, value of this parameter >>> will match the default value for the platform. When building on x86, we >>> need to tell clang that it should generate arm64 code anyways. There is >>> no reason in trying to make ARM build with x86 instruction set. >>> >>>> Also >>>> this affects both toolstack builds and hypervisor. Is applying -march >>>> like this actually appropriate for the toolstack? >>> >>> This is a good question. I can't see why this can't be appropriate for >>> toolstack. I.e. what bad can happen when building the toolstack. >> >> In the future, we may want to build the tools for Armv8-M. So I think >> the -march should also applies for the toolstack. > > Perhaps I don't know enough of the Arm world, but: Wouldn't it be possible > to build a tool stack suitable for a wide range for Arm64 flavors, while > requiring more targeted hypervisor binaries? Good question. There are some commonnality between ARMv8-M and ARMv8-R but I am not sure whether it means we could use -march=armv8-a build and run on ARMv8-M. Adding Ayan and Luca. Cheers, -- Julien Grall
HI, > On 2 Dec 2024, at 20:38, Julien Grall <julien@xen.org> wrote: > > Hi Jan, > > On 02/12/2024 07:52, Jan Beulich wrote: >> On 30.11.2024 18:15, Julien Grall wrote: >>> On 29/11/2024 22:12, Volodymyr Babchuk wrote: >>>> Jan Beulich <jbeulich@suse.com> writes: >>>>> On 29.11.2024 02:49, Volodymyr Babchuk wrote: >>>>>> --- a/config/arm64.mk >>>>>> +++ b/config/arm64.mk >>>>>> @@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX := >>>>>> CFLAGS += #-marm -march= -mcpu= etc >>>>>> +ifeq ($(clang),y) >>>>>> +CFLAGS += -target aarch64 -march=armv8-a >>>>>> +endif >>>>> >>>>> Why is this dependent on (just?) $(clang), not (also?) $(llvm)? >>>> >>>> Because this parameter is handled by clang only. There is no harm in >>>> providing it explicitly. When building on arm64, value of this parameter >>>> will match the default value for the platform. When building on x86, we >>>> need to tell clang that it should generate arm64 code anyways. There is >>>> no reason in trying to make ARM build with x86 instruction set. >>>> >>>>> Also >>>>> this affects both toolstack builds and hypervisor. Is applying -march >>>>> like this actually appropriate for the toolstack? >>>> >>>> This is a good question. I can't see why this can't be appropriate for >>>> toolstack. I.e. what bad can happen when building the toolstack. >>> >>> In the future, we may want to build the tools for Armv8-M. So I think >>> the -march should also applies for the toolstack. >> Perhaps I don't know enough of the Arm world, but: Wouldn't it be possible >> to build a tool stack suitable for a wide range for Arm64 flavors, while >> requiring more targeted hypervisor binaries? > > Good question. There are some commonnality between ARMv8-M and ARMv8-R but I am not sure whether it means we could use -march=armv8-a build and run on ARMv8-M. Adding Ayan and Luca. AFAIK a binary compiled for armv8-a aarch64 will work also on armv8-r aarch64 since they share almost everything apart from some MPU registers, instead in order to work on armv8-m we might need to pass the appropriate march Cheers, Luca
© 2016 - 2024 Red Hat, Inc.