[PATCH 0/2] Remaining ARM cross compile patches

[PATCH 0/2] Remaining ARM cross compile patches

[Ian Campbell]

One of these got missed somehow when I put the xenctx series together.
The other is new and fixes cross compiling the arm64 hypervisor in the
environment described at
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling

There is one remaining wrinkle which is this libc bug:
https://bugs.launchpad.net/linaro-aarch64/+bug/1169164

Which can be worked around with:
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 2f5ce18..d1753d8 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -219,6 +219,16 @@ typedef uint64_t xen_callback_t;
 
 /* 64 bit modes */
 #ifdef __aarch64__
+
+#undef PSR_MODE_BIT
+#undef PSR_MODE_EL3h
+#undef PSR_MODE_EL3t
+#undef PSR_MODE_EL2h
+#undef PSR_MODE_EL2t
+#undef PSR_MODE_EL1h
+#undef PSR_MODE_EL1t
+#undef PSR_MODE_EL0t
+
 #define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
 #define PSR_MODE_EL3h 0x0d
 #define PSR_MODE_EL3t 0x0c


Ian

[PATCH 1/2] xen: arm: correct platform detection in public header.

[Ian Campbell]

These headers cannot use the CONFIG_FOO defines provided when building Xen
(since they aren't provided when building tools or by external components) and
need to use the compiler provided architecture defines.

This manifested itself as a failure to build xenctx.c on ARM64 due to the
missing symbols contains .

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 xen/include/public/arch-arm.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 746df8e..2f5ce18 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -218,7 +218,7 @@ typedef uint64_t xen_callback_t;
 #define PSR_MODE_SYS 0x1f
 
 /* 64 bit modes */
-#ifdef CONFIG_ARM_64
+#ifdef __aarch64__
 #define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
 #define PSR_MODE_EL3h 0x0d
 #define PSR_MODE_EL3t 0x0c
-- 
1.7.2.5

Re: [PATCH 1/2] xen: arm: correct platform detection in public header.

[Stefano Stabellini]

On Fri, 26 Apr 2013, Ian Campbell wrote:
> These headers cannot use the CONFIG_FOO defines provided when building Xen
> (since they aren't provided when building tools or by external components) and
> need to use the compiler provided architecture defines.
> 
> This manifested itself as a failure to build xenctx.c on ARM64 due to the
> missing symbols contains .
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>


>  xen/include/public/arch-arm.h |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 746df8e..2f5ce18 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -218,7 +218,7 @@ typedef uint64_t xen_callback_t;
>  #define PSR_MODE_SYS 0x1f
>  
>  /* 64 bit modes */
> -#ifdef CONFIG_ARM_64
> +#ifdef __aarch64__
>  #define PSR_MODE_BIT  0x10 /* Set iff AArch32 */
>  #define PSR_MODE_EL3h 0x0d
>  #define PSR_MODE_EL3t 0x0c
> -- 
> 1.7.2.5
> 

Re: [PATCH 1/2] xen: arm: correct platform detection in public header.

[Ian Campbell]

On Fri, 2013-04-26 at 17:33 +0100, Stefano Stabellini wrote:
> On Fri, 26 Apr 2013, Ian Campbell wrote:
> > These headers cannot use the CONFIG_FOO defines provided when building Xen
> > (since they aren't provided when building tools or by external components) and
> > need to use the compiler provided architecture defines.
> > 
> > This manifested itself as a failure to build xenctx.c on ARM64 due to the
> > missing symbols contains .
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>

Applied, thanks.

[PATCH 2/2] xen: arm: drop LDFLAGS_DIRECT emulation specification.

[Ian Campbell]

The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring due
to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu gcc
bug, hwever when investigating I found that this option was not necessary at
all since we provide an explicit linker script when linking the hypervisor
(AFAICT all -m<foo> does is override the default linker script).

LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files but
-m<emulatin> is not needed for this since it isn't linking the final image and
we are calling the linker with the correct, cross if necessary, name.

However it does appear to be potentially useful to supply -EL in both cases to
ensure that we get little endian images. (I just happened to spot that Linux
does this, for both arm and arm64, although I expect we are unlikely to trip
over such toolchains these days).

Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 config/arm32.mk |    5 +----
 config/arm64.mk |    2 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/config/arm32.mk b/config/arm32.mk
index f64f0c1..683531c 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -10,9 +10,6 @@ CFLAGS += -marm
 HAS_PL011 := y
 
 # Use only if calling $(LD) directly.
-#LDFLAGS_DIRECT_OpenBSD = _obsd
-#LDFLAGS_DIRECT_FreeBSD = _fbsd
-LDFLAGS_DIRECT_Linux = _linux
-LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
+LDFLAGS_DIRECT += -EL
 
 CONFIG_LOAD_ADDRESS ?= 0x80000000
diff --git a/config/arm64.mk b/config/arm64.mk
index b2457eb..55b16da 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -7,6 +7,6 @@ CFLAGS += #-marm -march= -mcpu= etc
 HAS_PL011 := y
 
 # Use only if calling $(LD) directly.
-LDFLAGS_DIRECT += -maarch64elf
+LDFLAGS_DIRECT += -EL
 
 CONFIG_LOAD_ADDRESS ?= 0x80000000
-- 
1.7.2.5

Re: [PATCH 2/2] xen: arm: drop LDFLAGS_DIRECT emulation specification.

[Ian Campbell]

Ping?

On Fri, 2013-04-26 at 11:58 +0100, Ian Campbell wrote:
> The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring due
> to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu gcc
> bug, hwever when investigating I found that this option was not necessary at
> all since we provide an explicit linker script when linking the hypervisor
> (AFAICT all -m<foo> does is override the default linker script).
> 
> LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files but
> -m<emulatin> is not needed for this since it isn't linking the final image and
> we are calling the linker with the correct, cross if necessary, name.
> 
> However it does appear to be potentially useful to supply -EL in both cases to
> ensure that we get little endian images. (I just happened to spot that Linux
> does this, for both arm and arm64, although I expect we are unlikely to trip
> over such toolchains these days).
> 
> Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
>  config/arm32.mk |    5 +----
>  config/arm64.mk |    2 +-
>  2 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/config/arm32.mk b/config/arm32.mk
> index f64f0c1..683531c 100644
> --- a/config/arm32.mk
> +++ b/config/arm32.mk
> @@ -10,9 +10,6 @@ CFLAGS += -marm
>  HAS_PL011 := y
>  
>  # Use only if calling $(LD) directly.
> -#LDFLAGS_DIRECT_OpenBSD = _obsd
> -#LDFLAGS_DIRECT_FreeBSD = _fbsd
> -LDFLAGS_DIRECT_Linux = _linux
> -LDFLAGS_DIRECT += -marmelf$(LDFLAGS_DIRECT_$(XEN_OS))_eabi
> +LDFLAGS_DIRECT += -EL
>  
>  CONFIG_LOAD_ADDRESS ?= 0x80000000
> diff --git a/config/arm64.mk b/config/arm64.mk
> index b2457eb..55b16da 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -7,6 +7,6 @@ CFLAGS += #-marm -march= -mcpu= etc
>  HAS_PL011 := y
>  
>  # Use only if calling $(LD) directly.
> -LDFLAGS_DIRECT += -maarch64elf
> +LDFLAGS_DIRECT += -EL
>  
>  CONFIG_LOAD_ADDRESS ?= 0x80000000

Re: [PATCH 2/2] xen: arm: drop LDFLAGS_DIRECT emulation specification.

[Tim Deegan]

At 13:14 +0100 on 18 Jul (1374153286), Ian Campbell wrote:
> Ping?
> 
> On Fri, 2013-04-26 at 11:58 +0100, Ian Campbell wrote:
> > The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring due
> > to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu gcc
> > bug, hwever when investigating I found that this option was not necessary at
> > all since we provide an explicit linker script when linking the hypervisor
> > (AFAICT all -m<foo> does is override the default linker script).
> > 
> > LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files but
> > -m<emulatin> is not needed for this since it isn't linking the final image and
> > we are calling the linker with the correct, cross if necessary, name.
> > 
> > However it does appear to be potentially useful to supply -EL in both cases to
> > ensure that we get little endian images. (I just happened to spot that Linux
> > does this, for both arm and arm64, although I expect we are unlikely to trip
> > over such toolchains these days).
> > 
> > Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Tim Deegan <tim@xen.org>

Re: [PATCH 2/2] xen: arm: drop LDFLAGS_DIRECT emulation specification.

[Ian Campbell]

On Thu, 2013-07-18 at 18:09 +0100, Tim Deegan wrote:
> At 13:14 +0100 on 18 Jul (1374153286), Ian Campbell wrote:
> > Ping?
> > 
> > On Fri, 2013-04-26 at 11:58 +0100, Ian Campbell wrote:
> > > The current -maarch64elf fails when cross-building arm64 on Ubuntu Raring due
> > > to a missing file "ldscripts/aarch64elf.xr". This is undoubtedly an Ubuntu gcc
> > > bug, hwever when investigating I found that this option was not necessary at
> > > all since we provide an explicit linker script when linking the hypervisor
> > > (AFAICT all -m<foo> does is override the default linker script).
> > > 
> > > LDFLAGS_DIRECT is also used when linking the intermediate built-in.o files but
> > > -m<emulatin> is not needed for this since it isn't linking the final image and
> > > we are calling the linker with the correct, cross if necessary, name.
> > > 
> > > However it does appear to be potentially useful to supply -EL in both cases to
> > > ensure that we get little endian images. (I just happened to spot that Linux
> > > does this, for both arm and arm64, although I expect we are unlikely to trip
> > > over such toolchains these days).
> > > 
> > > Tested with cross-builds of arm32 and arm64 as well as a native arm32 build.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Tim Deegan <tim@xen.org>

Applied, thanks.