[PATCH 00/12] xen/arm: Add support to build with clang

[PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi all,

This series adds support to build Xen Arm with clang. This series was tested
with clang 8.0.

Note that I only did build for arm64. I still need to look at the arm32
build.

Cheers,

Julien Grall (12):
  xen: clang: Support correctly cross-compile
  xen/arm: fix get_cpu_info() when built with clang
  xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h
  xen/arm: memaccess: Initialize correctly *access in
    __p2m_get_mem_access
  xen/arm64: bitops: Match the register size with the value size in flsl
  xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit
    helpers
  xen/arm: cpuerrata: Match register size with value size in
    check_workaround_*
  xen/arm: cpufeature: Match register size with value size in
    cpus_have_const_cap
  xen/arm: guest_walk: Avoid theoritical unitialized value in
    get_top_bit
  xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused
  xen/arm: traps: Mark check_stack_alignment_constraints as unused
  xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline

 config/StdGNU.mk                                   |  9 +++++++--
 xen/arch/arm/guest_walk.c                          |  2 +-
 xen/arch/arm/mem_access.c                          |  2 +-
 xen/arch/arm/mm.c                                  |  3 ++-
 xen/arch/arm/traps.c                               |  3 ++-
 xen/include/asm-arm/arm64/bitops.h                 |  3 ++-
 xen/include/asm-arm/arm64/cmpxchg.h                | 10 ++++++----
 xen/include/asm-arm/arm64/sysregs.h                | 11 +++--------
 xen/include/asm-arm/cpuerrata.h                    |  2 +-
 xen/include/asm-arm/cpufeature.h                   |  2 +-
 xen/include/asm-arm/current.h                      | 10 +++++++++-
 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h |  2 +-
 12 files changed, 36 insertions(+), 23 deletions(-)

-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 01/12] xen: clang: Support correctly cross-compile

[Julien Grall]

Clang uses "-target" option for cross-compilation.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 config/StdGNU.mk | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 039274ea61..48c50b5ad7 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,8 +1,13 @@
 AS         = $(CROSS_COMPILE)as
 LD         = $(CROSS_COMPILE)ld
 ifeq ($(clang),y)
-CC         = $(CROSS_COMPILE)clang
-CXX        = $(CROSS_COMPILE)clang++
+ifneq ($(CROSS_COMPILE),)
+CC         = clang -target $(CROSS_COMPILE:-=)
+CXX        = clang++ -target $(CROSS_COMPILE:-=)
+else
+CC         = clang
+CXX        = clang++
+endif
 LD_LTO     = $(CROSS_COMPILE)llvm-ld
 else
 CC         = $(CROSS_COMPILE)gcc
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Julien Grall]

Clang understands the GCCism in use here, but still complains that sp is
unitialised. In such cases, resort to the older versions of this code,
which directly read sp into the temporary variable.

Note that we still keep the GCCism in the default case, as it causes GCC
to create rather better assembly.

This is based on the x86 counterpart.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/current.h | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
index c4af66fbb9..6b7c1df64d 100644
--- a/xen/include/asm-arm/current.h
+++ b/xen/include/asm-arm/current.h
@@ -28,8 +28,16 @@ struct cpu_info {
 
 static inline struct cpu_info *get_cpu_info(void)
 {
+#ifdef __clang__
+    unsigned long sp;
+
+    asm ("mov %0, sp" : "=r" (sp));
+#else
     register unsigned long sp asm ("sp");
-    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
+#endif
+
+    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) +
+                               STACK_SIZE - sizeof(struct cpu_info));
 }
 
 #define guest_cpu_user_regs() (&get_cpu_info()->guest_cpu_user_regs)
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 03/12] xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h

[Julien Grall]

The header guard for xilinx-zynqmp-eemi.h is not followed by a #define
of the macro used in the guard.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
index 72aadf7a44..cf25a9014d 100644
--- a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
+++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
@@ -12,7 +12,7 @@
  */
 
 #ifndef __ASM_ARM_PLATFORMS_ZYNQMP_H
-#define __ASM_ASM_PLATFORMS_ZYNQMP_H
+#define __ASM_ARM_PLATFORMS_ZYNQMP_H
 
 #include <asm/processor.h>
 #include <asm/smccc.h>
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 04/12] xen/arm: memaccess: Initialize correctly *access in __p2m_get_mem_access

[Julien Grall]

The commit 8d84e701fd "xen/arm: initialize access" initializes
*access using the wrong enumeration type. This result to a warning
using clang:

mem_access.c:50:20: error: implicit conversion from enumeration type
'p2m_access_t' to different enumeration type 'xenmem_access_t'
[-Werror,-Wenum-conversion]
    *access = p2m->default_access;
            ~ ~~~~~^~~~~~~~~~~~~~

The correct solution is to use the array memaccess that will do the
conversion between the 2 enums.

Fixes: 8d84e701fd ("xen/arm: initialize access")
Signed-off-by: Julien Grall <julien.grall@arm.com>

---

This patch is candidate for backporting in 4.12.
---
 xen/arch/arm/mem_access.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index db49372a2c..3e3620294c 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -47,7 +47,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
     };
 
     ASSERT(p2m_is_locked(p2m));
-    *access = p2m->default_access;
+    *access = memaccess[p2m->default_access];
 
     /* If no setting was ever set, just return rwx. */
     if ( !p2m->mem_access_enabled )
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Julien Grall]

Clang is pickier than GCC for the register size in asm statement. It expects
the register size to match the value size.

The instruction clz is expecting the two operands to be the same size
(i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
value, we need to make the destination variable 64-bit as well.

While at it, add a newline before the return statement.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/arm64/bitops.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
index 6bf1922680..05045f1109 100644
--- a/xen/include/asm-arm/arm64/bitops.h
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
 
 static inline int flsl(unsigned long x)
 {
-        int ret;
+        uint64_t ret;
 
         if (__builtin_constant_p(x))
                return generic_flsl(x);
 
         asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
+
         return BITS_PER_LONG - ret;
 }
 
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 06/12] xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit helpers

[Julien Grall]

Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.

The instructions msr/mrs are expecting a 64-bit register. This means the
implementation of the 32-bit helpers is not correct. The easiest
solution is to implement the 32-bit helpers using the 64-bit helpers.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/arm64/sysregs.h | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/xen/include/asm-arm/arm64/sysregs.h b/xen/include/asm-arm/arm64/sysregs.h
index 08585a969e..c60029d38f 100644
--- a/xen/include/asm-arm/arm64/sysregs.h
+++ b/xen/include/asm-arm/arm64/sysregs.h
@@ -59,14 +59,9 @@
 
 /* Access to system registers */
 
-#define READ_SYSREG32(name) ({                          \
-    uint32_t _r;                                        \
-    asm volatile("mrs  %0, "__stringify(name) : "=r" (_r));         \
-    _r; })
-#define WRITE_SYSREG32(v, name) do {                    \
-    uint32_t _r = v;                                    \
-    asm volatile("msr "__stringify(name)", %0" : : "r" (_r));       \
-} while (0)
+#define READ_SYSREG32(name) ((uint32_t)READ_SYSREG64(name))
+
+#define WRITE_SYSREG32(v, name) WRITE_SYSREG64((uint64_t)v, name)
 
 #define WRITE_SYSREG64(v, name) do {                    \
     uint64_t _r = v;                                    \
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.

The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
(resp. Arm64) whereas the value is a boolean (Clang consider to be
32-bit).

It would be possible to impose 32-bit register for both architecture
but this require the code to use __OP32. However, it does not really
improve the assembly generated. Instead, replace switch the variable
to use register_t.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/cpuerrata.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 55ddfda272..88ef3ca934 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)             \
         return false;                                           \
     else                                                        \
     {                                                           \
-        bool ret;                                               \
+        register_t ret;                                         \
                                                                 \
         asm volatile (ALTERNATIVE("mov %0, #0",                 \
                                   "mov %0, #1",                 \
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 08/12] xen/arm: cpufeature: Match register size with value size in cpus_have_const_cap

[Julien Grall]

Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the value size.

The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
(resp. Arm64) whereas the value is a boolean (Clang consider to be
32-bit).

It would be possible to impose 32-bit register for both architecture
but this require the code to use __OP32. However, it does no really
improve the assembly generated. Instead, replace switch the variable to
use register_t.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/cpufeature.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index c2c8f3417c..d06f09ecfa 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -67,7 +67,7 @@ static inline bool cpus_have_cap(unsigned int num)
 
 /* System capability check for constant cap */
 #define cpus_have_const_cap(num) ({                 \
-        bool __ret;                                 \
+        register_t __ret;                           \
                                                     \
         asm volatile (ALTERNATIVE("mov %0, #0",     \
                                   "mov %0, #1",     \
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 09/12] xen/arm: guest_walk: Avoid theoritical unitialized value in get_top_bit

[Julien Grall]

Clang 8.0 throws an error in the get_top_bit function:

guest_walk.c:328:15: error: variable 'topbit' is used uninitialized
whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
    else if ( is_64bit_domain(d) )
              ^~~~~~~~~~~~~~~~~~

This is happening because clang thinks that is_32bit_domain(d) is not
the exact inverse of is_64bit_domain(d). So it expects a else case to
handle the case where the latter call is false.

In other part of the code, dealing with difference between 32-bit and
64-bit domain, we usually use if ( is_XXbit_domain ) ... else ...

So use the same pattern here.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/guest_walk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index 7db7a7321b..1bee198777 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -325,7 +325,7 @@ static unsigned int get_top_bit(struct domain *d, vaddr_t gva, register_t tcr)
      */
     if ( is_32bit_domain(d) )
         topbit = 31;
-    else if ( is_64bit_domain(d) )
+    else
     {
         if ( ((gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI1)) ||
              (!(gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI0)) )
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 10/12] xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused

[Julien Grall]

Clang will throw an error if a function is unused unless you tell
to ignore it. This can be done using __maybe_unused.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/mm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 01ae2cccc0..d37925051a 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -160,7 +160,8 @@ unsigned long total_pages;
 extern char __init_begin[], __init_end[];
 
 /* Checking VA memory layout alignment. */
-static inline void check_memory_layout_alignment_constraints(void) {
+static __maybe_unused void check_memory_layout_alignment_constraints(void)
+{
     /* 2MB aligned regions */
     BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
     BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 11/12] xen/arm: traps: Mark check_stack_alignment_constraints as unused

[Julien Grall]

Clang will throw an error if a function is unused unless you tell
to ignore it. This can be done using __maybe_unused.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/arch/arm/traps.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d8b9a8a0f0..661475666a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -54,7 +54,8 @@
  * that both the kernel half of struct cpu_user_regs (which is pushed in
  * entry.S) and struct cpu_info (which lives at the bottom of a Xen
  * stack) must be doubleword-aligned in size.  */
-static inline void check_stack_alignment_constraints(void) {
+static void __maybe_unused check_stack_alignment_constraints(void)
+{
 #ifdef CONFIG_ARM_64
     BUILD_BUG_ON((sizeof (struct cpu_user_regs)) & 0xf);
     BUILD_BUG_ON((offsetof(struct cpu_user_regs, spsr_el1)) & 0xf);
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 12/12] xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline

[Julien Grall]

Currently __cmpxchg_mb and __cmpxchg are only marked inline. The
compiler is free to decide to not honor the inline. This will result to
generate code use __bad_cmpxchg and lead a link failure.

This was caught by Clang 8.0.

Signed-off-by: Julien Grall <julien.grall@arm.com>
---
 xen/include/asm-arm/arm64/cmpxchg.h | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/arm64/cmpxchg.h b/xen/include/asm-arm/arm64/cmpxchg.h
index ae42b2f5ff..359271173e 100644
--- a/xen/include/asm-arm/arm64/cmpxchg.h
+++ b/xen/include/asm-arm/arm64/cmpxchg.h
@@ -63,8 +63,9 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size
 
 extern void __bad_cmpxchg(volatile void *ptr, int size);
 
-static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
-				      unsigned long new, int size)
+static always_inline unsigned long __cmpxchg(volatile void *ptr,
+					     unsigned long old,
+					     unsigned long new, int size)
 {
 	unsigned long oldval = 0, res;
 
@@ -137,8 +138,9 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
 	return oldval;
 }
 
-static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
-					 unsigned long new, int size)
+static always_inline unsigned long __cmpxchg_mb(volatile void *ptr,
+						unsigned long old,
+						unsigned long new, int size)
 {
 	unsigned long ret;
 
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Andrew Cooper]

On 27/03/2019 18:45, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It expects
> the register size to match the value size.
>
> The instruction clz is expecting the two operands to be the same size
> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
> value, we need to make the destination variable 64-bit as well.
>
> While at it, add a newline before the return statement.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/arm64/bitops.h | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
> index 6bf1922680..05045f1109 100644
> --- a/xen/include/asm-arm/arm64/bitops.h
> +++ b/xen/include/asm-arm/arm64/bitops.h
> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
>  
>  static inline int flsl(unsigned long x)
>  {
> -        int ret;
> +        uint64_t ret;
>  
>          if (__builtin_constant_p(x))
>                 return generic_flsl(x);
>  
>          asm("clz\t%0, %1" : "=r" (ret) : "r" (x));

As x is fixed by the ABI, ret should be unsigned long to match, surely?

This will compile as it is arm64 specific, but it looks just as wrong
(per the commit message) as using int in the first place.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 04/12] xen/arm: memaccess: Initialize correctly *access in __p2m_get_mem_access

[Razvan Cojocaru]

On 3/27/19 8:45 PM, Julien Grall wrote:
> The commit 8d84e701fd "xen/arm: initialize access" initializes
> *access using the wrong enumeration type. This result to a warning
> using clang:
> 
> mem_access.c:50:20: error: implicit conversion from enumeration type
> 'p2m_access_t' to different enumeration type 'xenmem_access_t'
> [-Werror,-Wenum-conversion]
>     *access = p2m->default_access;
>             ~ ~~~~~^~~~~~~~~~~~~~
> 
> The correct solution is to use the array memaccess that will do the
> conversion between the 2 enums.
> 
> Fixes: 8d84e701fd ("xen/arm: initialize access")
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 10/12] xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused

[Andrew Cooper]

On 27/03/2019 18:45, Julien Grall wrote:
> Clang will throw an error if a function is unused unless you tell
> to ignore it. This can be done using __maybe_unused.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/arch/arm/mm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 01ae2cccc0..d37925051a 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -160,7 +160,8 @@ unsigned long total_pages;
>  extern char __init_begin[], __init_end[];
>  
>  /* Checking VA memory layout alignment. */
> -static inline void check_memory_layout_alignment_constraints(void) {
> +static __maybe_unused void check_memory_layout_alignment_constraints(void)

As you're already changing this...

The style used elsewhere is

static void __init __maybe_unused build_assertions(void)

which has the added advantage that it more obvious to future developers
that trying to put code other than BUILD_BUG_ON() in it is a bad idea.

It took me a moment to realise that this function deliberately wasn't
called.

~Andrew

> +{
>      /* 2MB aligned regions */
>      BUILD_BUG_ON(XEN_VIRT_START & ~SECOND_MASK);
>      BUILD_BUG_ON(FIXMAP_ADDR(0) & ~SECOND_MASK);


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 06/12] xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit helpers

[Andrew Cooper]

On 27/03/2019 18:45, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
>
> The instructions msr/mrs are expecting a 64-bit register. This means the
> implementation of the 32-bit helpers is not correct. The easiest
> solution is to implement the 32-bit helpers using the 64-bit helpers.
>
> Signed-off-by: Julien Grall <julien.grall@arm.com>

(I don't have an opinion on how to fix the issue, but)

Are SYSREGS actually always 64 bits even on arm32, and these helpers
just a shorthand for the lower 32 bits, or is this an
effectively-unnecessary constraint imposed by Clang?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Julien Grall]

Hi,

On 27/03/2019 19:03, Andrew Cooper wrote:
> On 27/03/2019 18:45, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It expects
>> the register size to match the value size.
>>
>> The instruction clz is expecting the two operands to be the same size
>> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
>> value, we need to make the destination variable 64-bit as well.
>>
>> While at it, add a newline before the return statement.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/include/asm-arm/arm64/bitops.h | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
>> index 6bf1922680..05045f1109 100644
>> --- a/xen/include/asm-arm/arm64/bitops.h
>> +++ b/xen/include/asm-arm/arm64/bitops.h
>> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
>>   
>>   static inline int flsl(unsigned long x)
>>   {
>> -        int ret;
>> +        uint64_t ret;
>>   
>>           if (__builtin_constant_p(x))
>>                  return generic_flsl(x);
>>   
>>           asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> 
> As x is fixed by the ABI, ret should be unsigned long to match, surely?

No need for it. The result of the instruction clz will always be smaller 
than 64.

I suspect they require a 64-bit register just for simplicity as they 
encode the size for the 2 registers in only a single bit (i.e sf).

> 
> This will compile as it is arm64 specific, but it looks just as wrong
> (per the commit message) as using int in the first place.
See above. I can clarify it in the commit message.

Cheers,

-- 
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 06/12] xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit helpers

[Julien Grall]

Hi,

On 27/03/2019 19:15, Andrew Cooper wrote:
> On 27/03/2019 18:45, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It
>> expects the register size to match the value size.
>>
>> The instructions msr/mrs are expecting a 64-bit register. This means the
>> implementation of the 32-bit helpers is not correct. The easiest
>> solution is to implement the 32-bit helpers using the 64-bit helpers.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
> 
> (I don't have an opinion on how to fix the issue, but)
> 
> Are SYSREGS actually always 64 bits even on arm32, and these helpers
> just a shorthand for the lower 32 bits, or is this an
> effectively-unnecessary constraint imposed by Clang?

This code is Arm64 specific. On Arm64, system registers are always 
64-bits, and therefore the instructions msr/mrs require a 64-bit register.

So the complain from Clang is valid here. It happens that some of the 
registers have the top 32-bit RES0 in current architecture. One could 
argue that this is not very future-proof and we should get rid of {READ, 
WRITE)_SYSREG32.

Unfortunately, the callers are expecting a 32-bit value. I need to 
investigate all the callers to ensure no one is transforming the value 
to 64-bit again. I don't really want to block clang support on that, so 
I have added an action for fixing this later on.

Cheers,

-- 
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Jan Beulich]

>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
> Clang uses "-target" option for cross-compilation.

And all possible targets are always available? I'd like to point out
that CROSS_COMPILE can be used for other than actual cross
compilation, e.g. building with just an alternative tool chain
built for the same target. Dropping the $(CROSS_COMPILE)
prefixes makes this impossible afaict. Requiring suitable wrapper
scripts to be put in place would seem better to me.

I also wonder why this change is needed for Arm, but wasn't
needed so far for x86. But perhaps no-one ever tried using it
so far ...

> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -1,8 +1,13 @@
>  AS         = $(CROSS_COMPILE)as
>  LD         = $(CROSS_COMPILE)ld
>  ifeq ($(clang),y)
> -CC         = $(CROSS_COMPILE)clang
> -CXX        = $(CROSS_COMPILE)clang++
> +ifneq ($(CROSS_COMPILE),)
> +CC         = clang -target $(CROSS_COMPILE:-=)
> +CXX        = clang++ -target $(CROSS_COMPILE:-=)

Is dropping dashes from the variable uniformly correct? If so,
could you please clarify in the commit message why that is?

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Andrew Cooper]

On 28/03/2019 09:55, Jan Beulich wrote:
>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>> Clang uses "-target" option for cross-compilation.
> And all possible targets are always available? I'd like to point out
> that CROSS_COMPILE can be used for other than actual cross
> compilation, e.g. building with just an alternative tool chain
> built for the same target. Dropping the $(CROSS_COMPILE)
> prefixes makes this impossible afaict. Requiring suitable wrapper
> scripts to be put in place would seem better to me.
>
> I also wonder why this change is needed for Arm, but wasn't
> needed so far for x86. But perhaps no-one ever tried using it
> so far ...

It seems that CROSS_COMPILE is a GNU-ism, which is not shared by the
clang world.  I can't find anything which will make you a
$FOO-$BAR-clang binary, whereas you do typically get clang-$X aliases
for the different versions of clang.

Using -target is from the Clang instructions on cross compilation, which
say to do it this way.  https://clang.llvm.org/docs/CrossCompilation.html

The targets supported will depend on the configuration Clang was
compiled with, but Clang specifically opposes GCC's way of requiring the
user to recompile for every different target.  It is expected that a
packager of clang will enable all of the supported targets in the
package they distribute.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Jan Beulich]

>>> On 28.03.19 at 11:14, <andrew.cooper3@citrix.com> wrote:
> On 28/03/2019 09:55, Jan Beulich wrote:
>>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>>> Clang uses "-target" option for cross-compilation.
>> And all possible targets are always available? I'd like to point out
>> that CROSS_COMPILE can be used for other than actual cross
>> compilation, e.g. building with just an alternative tool chain
>> built for the same target. Dropping the $(CROSS_COMPILE)
>> prefixes makes this impossible afaict. Requiring suitable wrapper
>> scripts to be put in place would seem better to me.
>>
>> I also wonder why this change is needed for Arm, but wasn't
>> needed so far for x86. But perhaps no-one ever tried using it
>> so far ...
> 
> It seems that CROSS_COMPILE is a GNU-ism, which is not shared by the
> clang world.  I can't find anything which will make you a
> $FOO-$BAR-clang binary, whereas you do typically get clang-$X aliases
> for the different versions of clang.

Oh, interesting. For my own re-built tool chains I actually can't use
CROSS_COMPILE either, because traditionally all my wrapper scripts
have a suffix like you say clang uses too. I patch in

cross-compile ?= $(CROSS_COMPILE)$(1)

locally as a fallback, to then use it as

AS = $(call cross-compile,as)

and then override things in the build root directory .config to
suite my actual needs, e.g. in its simplest possible form

cross-compile=$(1)x

But of course this doesn't fit clang either, as it's (aiui) only the
compiler which wants to be overridden this way.

> Using -target is from the Clang instructions on cross compilation, which
> say to do it this way.  https://clang.llvm.org/docs/CrossCompilation.html 
> 
> The targets supported will depend on the configuration Clang was
> compiled with, but Clang specifically opposes GCC's way of requiring the
> user to recompile for every different target.  It is expected that a
> packager of clang will enable all of the supported targets in the
> package they distribute.

Are you sure a distro caring about, say, only x86 would indeed
enable Arm and all sorts of other architectures in the compiler,
just because it can be enabled? IOW I assume the need for an
override to the system default clang binaries would still exist.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Andrew Cooper]

On 28/03/2019 10:28, Jan Beulich wrote:
>>>> On 28.03.19 at 11:14, <andrew.cooper3@citrix.com> wrote:
>> On 28/03/2019 09:55, Jan Beulich wrote:
>>>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>>>> Clang uses "-target" option for cross-compilation.
>>> And all possible targets are always available? I'd like to point out
>>> that CROSS_COMPILE can be used for other than actual cross
>>> compilation, e.g. building with just an alternative tool chain
>>> built for the same target. Dropping the $(CROSS_COMPILE)
>>> prefixes makes this impossible afaict. Requiring suitable wrapper
>>> scripts to be put in place would seem better to me.
>>>
>>> I also wonder why this change is needed for Arm, but wasn't
>>> needed so far for x86. But perhaps no-one ever tried using it
>>> so far ...
>> It seems that CROSS_COMPILE is a GNU-ism, which is not shared by the
>> clang world.  I can't find anything which will make you a
>> $FOO-$BAR-clang binary, whereas you do typically get clang-$X aliases
>> for the different versions of clang.
> Oh, interesting. For my own re-built tool chains I actually can't use
> CROSS_COMPILE either, because traditionally all my wrapper scripts
> have a suffix like you say clang uses too. I patch in
>
> cross-compile ?= $(CROSS_COMPILE)$(1)
>
> locally as a fallback, to then use it as
>
> AS = $(call cross-compile,as)
>
> and then override things in the build root directory .config to
> suite my actual needs, e.g. in its simplest possible form
>
> cross-compile=$(1)x
>
> But of course this doesn't fit clang either, as it's (aiui) only the
> compiler which wants to be overridden this way.
>
>> Using -target is from the Clang instructions on cross compilation, which
>> say to do it this way.  https://clang.llvm.org/docs/CrossCompilation.html 
>>
>> The targets supported will depend on the configuration Clang was
>> compiled with, but Clang specifically opposes GCC's way of requiring the
>> user to recompile for every different target.  It is expected that a
>> packager of clang will enable all of the supported targets in the
>> package they distribute.
> Are you sure a distro caring about, say, only x86 would indeed
> enable Arm and all sorts of other architectures in the compiler,
> just because it can be enabled? IOW I assume the need for an
> override to the system default clang binaries would still exist.

I've just tried, and Ubuntu 16.04's default clang-3.8 is perfectly happy
compiling Aarch64, and makes a suitable looking elf object.  (I can't
actually disassemble it because objdump chokes, but .text is the
expected length)

As the cross-compilation documentation states, this is a deliberate
design decision which, amongst other things, prevents distros from
needing to maintain per-arch packages.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Jan Beulich]

>>> On 28.03.19 at 11:43, <andrew.cooper3@citrix.com> wrote:
> On 28/03/2019 10:28, Jan Beulich wrote:
>>>>> On 28.03.19 at 11:14, <andrew.cooper3@citrix.com> wrote:
>>> Using -target is from the Clang instructions on cross compilation, which
>>> say to do it this way.  https://clang.llvm.org/docs/CrossCompilation.html 
>>>
>>> The targets supported will depend on the configuration Clang was
>>> compiled with, but Clang specifically opposes GCC's way of requiring the
>>> user to recompile for every different target.  It is expected that a
>>> packager of clang will enable all of the supported targets in the
>>> package they distribute.
>> Are you sure a distro caring about, say, only x86 would indeed
>> enable Arm and all sorts of other architectures in the compiler,
>> just because it can be enabled? IOW I assume the need for an
>> override to the system default clang binaries would still exist.
> 
> I've just tried, and Ubuntu 16.04's default clang-3.8 is perfectly happy
> compiling Aarch64, and makes a suitable looking elf object.  (I can't
> actually disassemble it because objdump chokes, but .text is the
> expected length)
> 
> As the cross-compilation documentation states, this is a deliberate
> design decision which, amongst other things, prevents distros from
> needing to maintain per-arch packages.

All understood, just that Ubuntu may not be a good example, as
there looks to be Ubuntu 16.04 for 64-bit Arm.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hi Julien,

On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> Hi all,
> 
> This series adds support to build Xen Arm with clang. This series was tested
> with clang 8.0.
> 
> Note that I only did build for arm64. I still need to look at the arm32
> build.
> 

I wonder if you have time to try the series with Arm Compiler 6? I am
asking because AFAIK it is based on clang/llvm [1] and there's a
safety-compliant version of it certified by TUV [2]. I don't have a
license yet so cannot try it myself but maybe you have access.

> 
> Cheers,
> 
> Julien Grall (12):
>   xen: clang: Support correctly cross-compile
>   xen/arm: fix get_cpu_info() when built with clang
>   xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h
>   xen/arm: memaccess: Initialize correctly *access in
>     __p2m_get_mem_access
>   xen/arm64: bitops: Match the register size with the value size in flsl
>   xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit
>     helpers
>   xen/arm: cpuerrata: Match register size with value size in
>     check_workaround_*
>   xen/arm: cpufeature: Match register size with value size in
>     cpus_have_const_cap
>   xen/arm: guest_walk: Avoid theoritical unitialized value in
>     get_top_bit
>   xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused
>   xen/arm: traps: Mark check_stack_alignment_constraints as unused
>   xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline
> 
>  config/StdGNU.mk                                   |  9 +++++++--
>  xen/arch/arm/guest_walk.c                          |  2 +-
>  xen/arch/arm/mem_access.c                          |  2 +-
>  xen/arch/arm/mm.c                                  |  3 ++-
>  xen/arch/arm/traps.c                               |  3 ++-
>  xen/include/asm-arm/arm64/bitops.h                 |  3 ++-
>  xen/include/asm-arm/arm64/cmpxchg.h                | 10 ++++++----
>  xen/include/asm-arm/arm64/sysregs.h                | 11 +++--------
>  xen/include/asm-arm/cpuerrata.h                    |  2 +-
>  xen/include/asm-arm/cpufeature.h                   |  2 +-
>  xen/include/asm-arm/current.h                      | 10 +++++++++-
>  xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h |  2 +-
>  12 files changed, 36 insertions(+), 23 deletions(-)
> 

[1] 
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.comp6/index.html

[2] 
https://store.developer.arm.com/store/embedded-iot-software-tools/arm-compiler-6-functional-safety?_ga=2.198817711.1237223028.1553771353-424456504.1550666847

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Julien Grall]

Hi,

On 28/03/2019 09:55, Jan Beulich wrote:
>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>> Clang uses "-target" option for cross-compilation.
> 
>> --- a/config/StdGNU.mk
>> +++ b/config/StdGNU.mk
>> @@ -1,8 +1,13 @@
>>   AS         = $(CROSS_COMPILE)as
>>   LD         = $(CROSS_COMPILE)ld
>>   ifeq ($(clang),y)
>> -CC         = $(CROSS_COMPILE)clang
>> -CXX        = $(CROSS_COMPILE)clang++
>> +ifneq ($(CROSS_COMPILE),)
>> +CC         = clang -target $(CROSS_COMPILE:-=)
>> +CXX        = clang++ -target $(CROSS_COMPILE:-=)
> 
> Is dropping dashes from the variable uniformly correct? If so,
> could you please clarify in the commit message why that is?
The target option requires the following format:

<arch><sub>-<vendor>-<sys>-<abi>

In other places, we need the trailing dash as GNU tools are using the same 
format as above with a dash to separate the tool name.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Julien Grall]

Hi,

On 28/03/2019 10:56, Jan Beulich wrote:
>>>> On 28.03.19 at 11:43, <andrew.cooper3@citrix.com> wrote:
>> On 28/03/2019 10:28, Jan Beulich wrote:
>>>>>> On 28.03.19 at 11:14, <andrew.cooper3@citrix.com> wrote:
>>>> Using -target is from the Clang instructions on cross compilation, which
>>>> say to do it this way.  https://clang.llvm.org/docs/CrossCompilation.html
>>>>
>>>> The targets supported will depend on the configuration Clang was
>>>> compiled with, but Clang specifically opposes GCC's way of requiring the
>>>> user to recompile for every different target.  It is expected that a
>>>> packager of clang will enable all of the supported targets in the
>>>> package they distribute.
>>> Are you sure a distro caring about, say, only x86 would indeed
>>> enable Arm and all sorts of other architectures in the compiler,
>>> just because it can be enabled? IOW I assume the need for an
>>> override to the system default clang binaries would still exist.
>>
>> I've just tried, and Ubuntu 16.04's default clang-3.8 is perfectly happy
>> compiling Aarch64, and makes a suitable looking elf object.  (I can't
>> actually disassemble it because objdump chokes, but .text is the
>> expected length)
>>
>> As the cross-compilation documentation states, this is a deliberate
>> design decision which, amongst other things, prevents distros from
>> needing to maintain per-arch packages.
> 
> All understood, just that Ubuntu may not be a good example, as
> there looks to be Ubuntu 16.04 for 64-bit Arm.

It occurs to me that other compiler may be based on clang/llvm but use a 
different name. For instance, the Arm Compiler is called armclang.

armclang only supports arm32 and arm64 and require to always pass the target 
triple using --target (Not the -- rather than -).

So we would need to cater different clang binary in the future.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

On 28/03/2019 11:27, Artem Mygaiev wrote:
> Hi Julien,

Hi Artem,

> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>> Hi all,
>>
>> This series adds support to build Xen Arm with clang. This series was tested
>> with clang 8.0.
>>
>> Note that I only did build for arm64. I still need to look at the arm32
>> build.
>>
> 
> I wonder if you have time to try the series with Arm Compiler 6? I am
> asking because AFAIK it is based on clang/llvm [1] and there's a
> safety-compliant version of it certified by TUV [2]. I don't have a
> license yet so cannot try it myself but maybe you have access.
I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk to 
pass armclang and the appropriate target option.

I also had a linking issue at the end where __2snprintf was not found. It seems 
the compiler replace snprintf with __2snprintf, I haven't figured out why yet.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Jan Beulich]

>>> On 29.03.19 at 10:41, <julien.grall@arm.com> wrote:
> On 28/03/2019 09:55, Jan Beulich wrote:
>>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>>> Clang uses "-target" option for cross-compilation.
>> 
>>> --- a/config/StdGNU.mk
>>> +++ b/config/StdGNU.mk
>>> @@ -1,8 +1,13 @@
>>>   AS         = $(CROSS_COMPILE)as
>>>   LD         = $(CROSS_COMPILE)ld
>>>   ifeq ($(clang),y)
>>> -CC         = $(CROSS_COMPILE)clang
>>> -CXX        = $(CROSS_COMPILE)clang++
>>> +ifneq ($(CROSS_COMPILE),)
>>> +CC         = clang -target $(CROSS_COMPILE:-=)
>>> +CXX        = clang++ -target $(CROSS_COMPILE:-=)
>> 
>> Is dropping dashes from the variable uniformly correct? If so,
>> could you please clarify in the commit message why that is?
> The target option requires the following format:
> 
> <arch><sub>-<vendor>-<sys>-<abi>
> 
> In other places, we need the trailing dash as GNU tools are using the same 
> format as above with a dash to separate the tool name.

Oh, I'm sorry - I keep forgetting that the substitution form you
use only fiddles with trailing dashes. Of course I won't insist, but
I'd prefer the more obvious $(patsubst %-,%,$(CROSS_COMPILE))
to be used instead, despite realizing that it's meaningfully longer.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 10/12] xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused

[Julien Grall]

Hi Andrew,

On 27/03/2019 19:10, Andrew Cooper wrote:
> On 27/03/2019 18:45, Julien Grall wrote:
>> Clang will throw an error if a function is unused unless you tell
>> to ignore it. This can be done using __maybe_unused.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/arch/arm/mm.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>> index 01ae2cccc0..d37925051a 100644
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -160,7 +160,8 @@ unsigned long total_pages;
>>   extern char __init_begin[], __init_end[];
>>   
>>   /* Checking VA memory layout alignment. */
>> -static inline void check_memory_layout_alignment_constraints(void) {
>> +static __maybe_unused void check_memory_layout_alignment_constraints(void)
> 
> As you're already changing this...
> 
> The style used elsewhere is
> 
> static void __init __maybe_unused build_assertions(void)
> 
> which has the added advantage that it more obvious to future developers
> that trying to put code other than BUILD_BUG_ON() in it is a bad idea.

Good point. I will update this patch (and the following one) to rename the 
function as well.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 10/12] xen/arm: mm: Mark check_memory_layout_alignment_constraints as unused

[Julien Grall]

Hi Andrew,

On 27/03/2019 19:10, Andrew Cooper wrote:
> On 27/03/2019 18:45, Julien Grall wrote:
>> Clang will throw an error if a function is unused unless you tell
>> to ignore it. This can be done using __maybe_unused.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/arch/arm/mm.c | 3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>> index 01ae2cccc0..d37925051a 100644
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -160,7 +160,8 @@ unsigned long total_pages;
>>   extern char __init_begin[], __init_end[];
>>   
>>   /* Checking VA memory layout alignment. */
>> -static inline void check_memory_layout_alignment_constraints(void) {
>> +static __maybe_unused void check_memory_layout_alignment_constraints(void)
> 
> As you're already changing this...
> 
> The style used elsewhere is
> 
> static void __init __maybe_unused build_assertions(void)
> 
> which has the added advantage that it more obvious to future developers
> that trying to put code other than BUILD_BUG_ON() in it is a bad idea.

Good point. I will update this patch (and the following one) to rename the 
function as well.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Stefano Stabellini]

On Fri, 29 Mar 2019, Julien Grall wrote:
> On 28/03/2019 11:27, Artem Mygaiev wrote:
> > Hi Julien,
> 
> Hi Artem,
> 
> > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > Hi all,
> > > 
> > > This series adds support to build Xen Arm with clang. This series was
> > > tested
> > > with clang 8.0.
> > > 
> > > Note that I only did build for arm64. I still need to look at the arm32
> > > build.
> > > 
> > 
> > I wonder if you have time to try the series with Arm Compiler 6? I am
> > asking because AFAIK it is based on clang/llvm [1] and there's a
> > safety-compliant version of it certified by TUV [2]. I don't have a
> > license yet so cannot try it myself but maybe you have access.
> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
> to pass armclang and the appropriate target option.
> 
> I also had a linking issue at the end where __2snprintf was not found. It
> seems the compiler replace snprintf with __2snprintf, I haven't figured out
> why yet.

But after these changes, does it work?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Stefano Stabellini]

On Fri, 29 Mar 2019, Julien Grall wrote:
> On 28/03/2019 11:27, Artem Mygaiev wrote:
> > Hi Julien,
> 
> Hi Artem,
> 
> > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > Hi all,
> > > 
> > > This series adds support to build Xen Arm with clang. This series was
> > > tested
> > > with clang 8.0.
> > > 
> > > Note that I only did build for arm64. I still need to look at the arm32
> > > build.
> > > 
> > 
> > I wonder if you have time to try the series with Arm Compiler 6? I am
> > asking because AFAIK it is based on clang/llvm [1] and there's a
> > safety-compliant version of it certified by TUV [2]. I don't have a
> > license yet so cannot try it myself but maybe you have access.
> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
> to pass armclang and the appropriate target option.
> 
> I also had a linking issue at the end where __2snprintf was not found. It
> seems the compiler replace snprintf with __2snprintf, I haven't figured out
> why yet.

But after these changes, does it work?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi,

On 16/04/2019 23:43, Stefano Stabellini wrote:
> On Fri, 29 Mar 2019, Julien Grall wrote:
>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>> Hi Julien,
>>
>> Hi Artem,
>>
>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>> Hi all,
>>>>
>>>> This series adds support to build Xen Arm with clang. This series was
>>>> tested
>>>> with clang 8.0.
>>>>
>>>> Note that I only did build for arm64. I still need to look at the arm32
>>>> build.
>>>>
>>>
>>> I wonder if you have time to try the series with Arm Compiler 6? I am
>>> asking because AFAIK it is based on clang/llvm [1] and there's a
>>> safety-compliant version of it certified by TUV [2]. I don't have a
>>> license yet so cannot try it myself but maybe you have access.
>> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
>> to pass armclang and the appropriate target option.
>>
>> I also had a linking issue at the end where __2snprintf was not found. It
>> seems the compiler replace snprintf with __2snprintf, I haven't figured out
>> why yet.
> 
> But after these changes, does it work?

I haven't tried to fix the linking issues. I only gave a quick try because Artem 
asked. I have no plan at the moment to go further than that for now.

Patches are welcomed to add support for armclang.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi,

On 16/04/2019 23:43, Stefano Stabellini wrote:
> On Fri, 29 Mar 2019, Julien Grall wrote:
>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>> Hi Julien,
>>
>> Hi Artem,
>>
>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>> Hi all,
>>>>
>>>> This series adds support to build Xen Arm with clang. This series was
>>>> tested
>>>> with clang 8.0.
>>>>
>>>> Note that I only did build for arm64. I still need to look at the arm32
>>>> build.
>>>>
>>>
>>> I wonder if you have time to try the series with Arm Compiler 6? I am
>>> asking because AFAIK it is based on clang/llvm [1] and there's a
>>> safety-compliant version of it certified by TUV [2]. I don't have a
>>> license yet so cannot try it myself but maybe you have access.
>> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
>> to pass armclang and the appropriate target option.
>>
>> I also had a linking issue at the end where __2snprintf was not found. It
>> seems the compiler replace snprintf with __2snprintf, I haven't figured out
>> why yet.
> 
> But after these changes, does it work?

I haven't tried to fix the linking issues. I only gave a quick try because Artem 
asked. I have no plan at the moment to go further than that for now.

Patches are welcomed to add support for armclang.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 03/12] xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> The header guard for xilinx-zynqmp-eemi.h is not followed by a #define
> of the macro used in the guard.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> index 72aadf7a44..cf25a9014d 100644
> --- a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> +++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> @@ -12,7 +12,7 @@
>   */
>  
>  #ifndef __ASM_ARM_PLATFORMS_ZYNQMP_H
> -#define __ASM_ASM_PLATFORMS_ZYNQMP_H
> +#define __ASM_ARM_PLATFORMS_ZYNQMP_H
>  
>  #include <asm/processor.h>
>  #include <asm/smccc.h>
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 03/12] xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> The header guard for xilinx-zynqmp-eemi.h is not followed by a #define
> of the macro used in the guard.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> index 72aadf7a44..cf25a9014d 100644
> --- a/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> +++ b/xen/include/asm-arm/platforms/xilinx-zynqmp-eemi.h
> @@ -12,7 +12,7 @@
>   */
>  
>  #ifndef __ASM_ARM_PLATFORMS_ZYNQMP_H
> -#define __ASM_ASM_PLATFORMS_ZYNQMP_H
> +#define __ASM_ARM_PLATFORMS_ZYNQMP_H
>  
>  #include <asm/processor.h>
>  #include <asm/smccc.h>
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Hi,
> 
> On 27/03/2019 19:03, Andrew Cooper wrote:
> > On 27/03/2019 18:45, Julien Grall wrote:
> >> Clang is pickier than GCC for the register size in asm statement. It expects
> >> the register size to match the value size.
> >>
> >> The instruction clz is expecting the two operands to be the same size
> >> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
> >> value, we need to make the destination variable 64-bit as well.
> >>
> >> While at it, add a newline before the return statement.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@arm.com>
> >> ---
> >>   xen/include/asm-arm/arm64/bitops.h | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
> >> index 6bf1922680..05045f1109 100644
> >> --- a/xen/include/asm-arm/arm64/bitops.h
> >> +++ b/xen/include/asm-arm/arm64/bitops.h
> >> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
> >>   
> >>   static inline int flsl(unsigned long x)
> >>   {
> >> -        int ret;
> >> +        uint64_t ret;
> >>   
> >>           if (__builtin_constant_p(x))
> >>                  return generic_flsl(x);
> >>   
> >>           asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> > 
> > As x is fixed by the ABI, ret should be unsigned long to match, surely?
> 
> No need for it. The result of the instruction clz will always be smaller 
> than 64.
> 
> I suspect they require a 64-bit register just for simplicity as they 
> encode the size for the 2 registers in only a single bit (i.e sf).
> 
> > 
> > This will compile as it is arm64 specific, but it looks just as wrong
> > (per the commit message) as using int in the first place.
> See above. I can clarify it in the commit message.

I agree with Andrew: I can see that the code is correct, but it really
looks wrong at first sight. Why not use unsigned long? This is an arm64
header anyway.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Hi,
> 
> On 27/03/2019 19:03, Andrew Cooper wrote:
> > On 27/03/2019 18:45, Julien Grall wrote:
> >> Clang is pickier than GCC for the register size in asm statement. It expects
> >> the register size to match the value size.
> >>
> >> The instruction clz is expecting the two operands to be the same size
> >> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
> >> value, we need to make the destination variable 64-bit as well.
> >>
> >> While at it, add a newline before the return statement.
> >>
> >> Signed-off-by: Julien Grall <julien.grall@arm.com>
> >> ---
> >>   xen/include/asm-arm/arm64/bitops.h | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
> >> index 6bf1922680..05045f1109 100644
> >> --- a/xen/include/asm-arm/arm64/bitops.h
> >> +++ b/xen/include/asm-arm/arm64/bitops.h
> >> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
> >>   
> >>   static inline int flsl(unsigned long x)
> >>   {
> >> -        int ret;
> >> +        uint64_t ret;
> >>   
> >>           if (__builtin_constant_p(x))
> >>                  return generic_flsl(x);
> >>   
> >>           asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> > 
> > As x is fixed by the ABI, ret should be unsigned long to match, surely?
> 
> No need for it. The result of the instruction clz will always be smaller 
> than 64.
> 
> I suspect they require a 64-bit register just for simplicity as they 
> encode the size for the 2 registers in only a single bit (i.e sf).
> 
> > 
> > This will compile as it is arm64 specific, but it looks just as wrong
> > (per the commit message) as using int in the first place.
> See above. I can clarify it in the commit message.

I agree with Andrew: I can see that the code is correct, but it really
looks wrong at first sight. Why not use unsigned long? This is an arm64
header anyway.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 06/12] xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit helpers

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
> 
> The instructions msr/mrs are expecting a 64-bit register. This means the
> implementation of the 32-bit helpers is not correct. The easiest
> solution is to implement the 32-bit helpers using the 64-bit helpers.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/include/asm-arm/arm64/sysregs.h | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/include/asm-arm/arm64/sysregs.h b/xen/include/asm-arm/arm64/sysregs.h
> index 08585a969e..c60029d38f 100644
> --- a/xen/include/asm-arm/arm64/sysregs.h
> +++ b/xen/include/asm-arm/arm64/sysregs.h
> @@ -59,14 +59,9 @@
>  
>  /* Access to system registers */
>  
> -#define READ_SYSREG32(name) ({                          \
> -    uint32_t _r;                                        \
> -    asm volatile("mrs  %0, "__stringify(name) : "=r" (_r));         \
> -    _r; })
> -#define WRITE_SYSREG32(v, name) do {                    \
> -    uint32_t _r = v;                                    \
> -    asm volatile("msr "__stringify(name)", %0" : : "r" (_r));       \
> -} while (0)
> +#define READ_SYSREG32(name) ((uint32_t)READ_SYSREG64(name))
> +
> +#define WRITE_SYSREG32(v, name) WRITE_SYSREG64((uint64_t)v, name)
>  
>  #define WRITE_SYSREG64(v, name) do {                    \
>      uint64_t _r = v;                                    \
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 06/12] xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit helpers

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
> 
> The instructions msr/mrs are expecting a 64-bit register. This means the
> implementation of the 32-bit helpers is not correct. The easiest
> solution is to implement the 32-bit helpers using the 64-bit helpers.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/include/asm-arm/arm64/sysregs.h | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/include/asm-arm/arm64/sysregs.h b/xen/include/asm-arm/arm64/sysregs.h
> index 08585a969e..c60029d38f 100644
> --- a/xen/include/asm-arm/arm64/sysregs.h
> +++ b/xen/include/asm-arm/arm64/sysregs.h
> @@ -59,14 +59,9 @@
>  
>  /* Access to system registers */
>  
> -#define READ_SYSREG32(name) ({                          \
> -    uint32_t _r;                                        \
> -    asm volatile("mrs  %0, "__stringify(name) : "=r" (_r));         \
> -    _r; })
> -#define WRITE_SYSREG32(v, name) do {                    \
> -    uint32_t _r = v;                                    \
> -    asm volatile("msr "__stringify(name)", %0" : : "r" (_r));       \
> -} while (0)
> +#define READ_SYSREG32(name) ((uint32_t)READ_SYSREG64(name))
> +
> +#define WRITE_SYSREG32(v, name) WRITE_SYSREG64((uint64_t)v, name)
>  
>  #define WRITE_SYSREG64(v, name) do {                    \
>      uint64_t _r = v;                                    \
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
> 
> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> (resp. Arm64) whereas the value is a boolean (Clang consider to be
> 32-bit).
> 
> It would be possible to impose 32-bit register for both architecture
> but this require the code to use __OP32. However, it does not really
> improve the assembly generated. Instead, replace switch the variable
> to use register_t.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/cpuerrata.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index 55ddfda272..88ef3ca934 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)             \
>          return false;                                           \
>      else                                                        \
>      {                                                           \
> -        bool ret;                                               \
> +        register_t ret;                                         \
>                                                                  \
>          asm volatile (ALTERNATIVE("mov %0, #0",                 \
>                                    "mov %0, #1",                 \

This is OK. Could you please also change the return statement below?
Maybe something like:

  return unlikely(!!ret);

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
> 
> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> (resp. Arm64) whereas the value is a boolean (Clang consider to be
> 32-bit).
> 
> It would be possible to impose 32-bit register for both architecture
> but this require the code to use __OP32. However, it does not really
> improve the assembly generated. Instead, replace switch the variable
> to use register_t.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/cpuerrata.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
> index 55ddfda272..88ef3ca934 100644
> --- a/xen/include/asm-arm/cpuerrata.h
> +++ b/xen/include/asm-arm/cpuerrata.h
> @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)             \
>          return false;                                           \
>      else                                                        \
>      {                                                           \
> -        bool ret;                                               \
> +        register_t ret;                                         \
>                                                                  \
>          asm volatile (ALTERNATIVE("mov %0, #0",                 \
>                                    "mov %0, #1",                 \

This is OK. Could you please also change the return statement below?
Maybe something like:

  return unlikely(!!ret);

Thank you!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 08/12] xen/arm: cpufeature: Match register size with value size in cpus_have_const_cap

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
> 
> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> (resp. Arm64) whereas the value is a boolean (Clang consider to be
> 32-bit).
> 
> It would be possible to impose 32-bit register for both architecture
> but this require the code to use __OP32. However, it does no really
> improve the assembly generated. Instead, replace switch the variable to
> use register_t.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/cpufeature.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
> index c2c8f3417c..d06f09ecfa 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -67,7 +67,7 @@ static inline bool cpus_have_cap(unsigned int num)
>  
>  /* System capability check for constant cap */
>  #define cpus_have_const_cap(num) ({                 \
> -        bool __ret;                                 \
> +        register_t __ret;                           \
>                                                      \
>          asm volatile (ALTERNATIVE("mov %0, #0",     \
>                                    "mov %0, #1",     \

As per the previous one, this is fine, but could you also change the
last statement below to unlikely(!!__ret);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 08/12] xen/arm: cpufeature: Match register size with value size in cpus_have_const_cap

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang is pickier than GCC for the register size in asm statement. It
> expects the register size to match the value size.
> 
> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> (resp. Arm64) whereas the value is a boolean (Clang consider to be
> 32-bit).
> 
> It would be possible to impose 32-bit register for both architecture
> but this require the code to use __OP32. However, it does no really
> improve the assembly generated. Instead, replace switch the variable to
> use register_t.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/cpufeature.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
> index c2c8f3417c..d06f09ecfa 100644
> --- a/xen/include/asm-arm/cpufeature.h
> +++ b/xen/include/asm-arm/cpufeature.h
> @@ -67,7 +67,7 @@ static inline bool cpus_have_cap(unsigned int num)
>  
>  /* System capability check for constant cap */
>  #define cpus_have_const_cap(num) ({                 \
> -        bool __ret;                                 \
> +        register_t __ret;                           \
>                                                      \
>          asm volatile (ALTERNATIVE("mov %0, #0",     \
>                                    "mov %0, #1",     \

As per the previous one, this is fine, but could you also change the
last statement below to unlikely(!!__ret);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 09/12] xen/arm: guest_walk: Avoid theoritical unitialized value in get_top_bit

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang 8.0 throws an error in the get_top_bit function:
> 
> guest_walk.c:328:15: error: variable 'topbit' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>     else if ( is_64bit_domain(d) )
>               ^~~~~~~~~~~~~~~~~~
> 
> This is happening because clang thinks that is_32bit_domain(d) is not
> the exact inverse of is_64bit_domain(d). So it expects a else case to
> handle the case where the latter call is false.
> 
> In other part of the code, dealing with difference between 32-bit and
> 64-bit domain, we usually use if ( is_XXbit_domain ) ... else ...
> 
> So use the same pattern here.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/arm/guest_walk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index 7db7a7321b..1bee198777 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -325,7 +325,7 @@ static unsigned int get_top_bit(struct domain *d, vaddr_t gva, register_t tcr)
>       */
>      if ( is_32bit_domain(d) )
>          topbit = 31;
> -    else if ( is_64bit_domain(d) )
> +    else
>      {
>          if ( ((gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI1)) ||
>               (!(gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI0)) )
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 09/12] xen/arm: guest_walk: Avoid theoritical unitialized value in get_top_bit

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang 8.0 throws an error in the get_top_bit function:
> 
> guest_walk.c:328:15: error: variable 'topbit' is used uninitialized
> whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>     else if ( is_64bit_domain(d) )
>               ^~~~~~~~~~~~~~~~~~
> 
> This is happening because clang thinks that is_32bit_domain(d) is not
> the exact inverse of is_64bit_domain(d). So it expects a else case to
> handle the case where the latter call is false.
> 
> In other part of the code, dealing with difference between 32-bit and
> 64-bit domain, we usually use if ( is_XXbit_domain ) ... else ...
> 
> So use the same pattern here.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/arch/arm/guest_walk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index 7db7a7321b..1bee198777 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -325,7 +325,7 @@ static unsigned int get_top_bit(struct domain *d, vaddr_t gva, register_t tcr)
>       */
>      if ( is_32bit_domain(d) )
>          topbit = 31;
> -    else if ( is_64bit_domain(d) )
> +    else
>      {
>          if ( ((gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI1)) ||
>               (!(gva & BIT_ULL(55)) && (tcr & TCR_EL1_TBI0)) )
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 12/12] xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Currently __cmpxchg_mb and __cmpxchg are only marked inline. The
> compiler is free to decide to not honor the inline. This will result to
> generate code use __bad_cmpxchg and lead a link failure.
> 
> This was caught by Clang 8.0.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/include/asm-arm/arm64/cmpxchg.h | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/arm64/cmpxchg.h b/xen/include/asm-arm/arm64/cmpxchg.h
> index ae42b2f5ff..359271173e 100644
> --- a/xen/include/asm-arm/arm64/cmpxchg.h
> +++ b/xen/include/asm-arm/arm64/cmpxchg.h
> @@ -63,8 +63,9 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size
>  
>  extern void __bad_cmpxchg(volatile void *ptr, int size);
>  
> -static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
> -				      unsigned long new, int size)
> +static always_inline unsigned long __cmpxchg(volatile void *ptr,
> +					     unsigned long old,
> +					     unsigned long new, int size)
>  {
>  	unsigned long oldval = 0, res;
>  
> @@ -137,8 +138,9 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
>  	return oldval;
>  }
>  
> -static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
> -					 unsigned long new, int size)
> +static always_inline unsigned long __cmpxchg_mb(volatile void *ptr,
> +						unsigned long old,
> +						unsigned long new, int size)
>  {
>  	unsigned long ret;
>  
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 12/12] xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Currently __cmpxchg_mb and __cmpxchg are only marked inline. The
> compiler is free to decide to not honor the inline. This will result to
> generate code use __bad_cmpxchg and lead a link failure.
> 
> This was caught by Clang 8.0.
> 
> Signed-off-by: Julien Grall <julien.grall@arm.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  xen/include/asm-arm/arm64/cmpxchg.h | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/arm64/cmpxchg.h b/xen/include/asm-arm/arm64/cmpxchg.h
> index ae42b2f5ff..359271173e 100644
> --- a/xen/include/asm-arm/arm64/cmpxchg.h
> +++ b/xen/include/asm-arm/arm64/cmpxchg.h
> @@ -63,8 +63,9 @@ static inline unsigned long __xchg(unsigned long x, volatile void *ptr, int size
>  
>  extern void __bad_cmpxchg(volatile void *ptr, int size);
>  
> -static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
> -				      unsigned long new, int size)
> +static always_inline unsigned long __cmpxchg(volatile void *ptr,
> +					     unsigned long old,
> +					     unsigned long new, int size)
>  {
>  	unsigned long oldval = 0, res;
>  
> @@ -137,8 +138,9 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old,
>  	return oldval;
>  }
>  
> -static inline unsigned long __cmpxchg_mb(volatile void *ptr, unsigned long old,
> -					 unsigned long new, int size)
> +static always_inline unsigned long __cmpxchg_mb(volatile void *ptr,
> +						unsigned long old,
> +						unsigned long new, int size)
>  {
>  	unsigned long ret;
>  
> -- 
> 2.11.0
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang understands the GCCism in use here, but still complains that sp is
> unitialised. In such cases, resort to the older versions of this code,
> which directly read sp into the temporary variable.
> 
> Note that we still keep the GCCism in the default case, as it causes GCC
> to create rather better assembly.
> 
> This is based on the x86 counterpart.

I understand this is based on an existing approach but what about other
compilers? I have a suggestion below.


> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/current.h | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
> index c4af66fbb9..6b7c1df64d 100644
> --- a/xen/include/asm-arm/current.h
> +++ b/xen/include/asm-arm/current.h
> @@ -28,8 +28,16 @@ struct cpu_info {
>  
>  static inline struct cpu_info *get_cpu_info(void)
>  {
> +#ifdef __clang__
> +    unsigned long sp;
> +
> +    asm ("mov %0, sp" : "=r" (sp));
> +#else
>      register unsigned long sp asm ("sp");
> -    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
> +#endif
> +
> +    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) +
> +                               STACK_SIZE - sizeof(struct cpu_info));
>  }

I think it makes sense to switch the #ifdef around:

#ifdef __GNUC__
    /* gcc specific optimization */
#else
   /* regular implementation */
#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Stefano Stabellini]

On Wed, 27 Mar 2019, Julien Grall wrote:
> Clang understands the GCCism in use here, but still complains that sp is
> unitialised. In such cases, resort to the older versions of this code,
> which directly read sp into the temporary variable.
> 
> Note that we still keep the GCCism in the default case, as it causes GCC
> to create rather better assembly.
> 
> This is based on the x86 counterpart.

I understand this is based on an existing approach but what about other
compilers? I have a suggestion below.


> Signed-off-by: Julien Grall <julien.grall@arm.com>
> ---
>  xen/include/asm-arm/current.h | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/current.h b/xen/include/asm-arm/current.h
> index c4af66fbb9..6b7c1df64d 100644
> --- a/xen/include/asm-arm/current.h
> +++ b/xen/include/asm-arm/current.h
> @@ -28,8 +28,16 @@ struct cpu_info {
>  
>  static inline struct cpu_info *get_cpu_info(void)
>  {
> +#ifdef __clang__
> +    unsigned long sp;
> +
> +    asm ("mov %0, sp" : "=r" (sp));
> +#else
>      register unsigned long sp asm ("sp");
> -    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) + STACK_SIZE - sizeof(struct cpu_info));
> +#endif
> +
> +    return (struct cpu_info *)((sp & ~(STACK_SIZE - 1)) +
> +                               STACK_SIZE - sizeof(struct cpu_info));
>  }

I think it makes sense to switch the #ifdef around:

#ifdef __GNUC__
    /* gcc specific optimization */
#else
   /* regular implementation */
#endif

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Julien Grall]

Hi,

On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Clang understands the GCCism in use here, but still complains that sp is
>> unitialised. In such cases, resort to the older versions of this code,
>> which directly read sp into the temporary variable.
>>
>> Note that we still keep the GCCism in the default case, as it causes GCC
>> to create rather better assembly.
>>
>> This is based on the x86 counterpart.
> 
> I understand this is based on an existing approach but what about other
> compilers? I have a suggestion below.

What if the compiler actually support named registers? Why would we make 
the code less efficient?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Julien Grall]

Hi,

On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Clang understands the GCCism in use here, but still complains that sp is
>> unitialised. In such cases, resort to the older versions of this code,
>> which directly read sp into the temporary variable.
>>
>> Note that we still keep the GCCism in the default case, as it causes GCC
>> to create rather better assembly.
>>
>> This is based on the x86 counterpart.
> 
> I understand this is based on an existing approach but what about other
> compilers? I have a suggestion below.

What if the compiler actually support named registers? Why would we make 
the code less efficient?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Julien Grall]

Hi,

On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Hi,
>>
>> On 27/03/2019 19:03, Andrew Cooper wrote:
>>> On 27/03/2019 18:45, Julien Grall wrote:
>>>> Clang is pickier than GCC for the register size in asm statement. It expects
>>>> the register size to match the value size.
>>>>
>>>> The instruction clz is expecting the two operands to be the same size
>>>> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
>>>> value, we need to make the destination variable 64-bit as well.
>>>>
>>>> While at it, add a newline before the return statement.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    xen/include/asm-arm/arm64/bitops.h | 3 ++-
>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
>>>> index 6bf1922680..05045f1109 100644
>>>> --- a/xen/include/asm-arm/arm64/bitops.h
>>>> +++ b/xen/include/asm-arm/arm64/bitops.h
>>>> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
>>>>    
>>>>    static inline int flsl(unsigned long x)
>>>>    {
>>>> -        int ret;
>>>> +        uint64_t ret;
>>>>    
>>>>            if (__builtin_constant_p(x))
>>>>                   return generic_flsl(x);
>>>>    
>>>>            asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
>>>
>>> As x is fixed by the ABI, ret should be unsigned long to match, surely?
>>
>> No need for it. The result of the instruction clz will always be smaller
>> than 64.
>>
>> I suspect they require a 64-bit register just for simplicity as they
>> encode the size for the 2 registers in only a single bit (i.e sf).
>>
>>>
>>> This will compile as it is arm64 specific, but it looks just as wrong
>>> (per the commit message) as using int in the first place.
>> See above. I can clarify it in the commit message.
> 
> I agree with Andrew: I can see that the code is correct, but it really
> looks wrong at first sight. Why not use unsigned long? This is an arm64
> header anyway.

While this is implemented in arm64, this is a function used in common 
code... So the prototype would have to be changed everywhere.

However, as I pointed out this is a design decision from Arm64 and I 
think it would be wrong to return unsigned long.

I offered the suggestion to update the commit message. I can also add a 
comment in the code.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Julien Grall]

Hi,

On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Hi,
>>
>> On 27/03/2019 19:03, Andrew Cooper wrote:
>>> On 27/03/2019 18:45, Julien Grall wrote:
>>>> Clang is pickier than GCC for the register size in asm statement. It expects
>>>> the register size to match the value size.
>>>>
>>>> The instruction clz is expecting the two operands to be the same size
>>>> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
>>>> value, we need to make the destination variable 64-bit as well.
>>>>
>>>> While at it, add a newline before the return statement.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    xen/include/asm-arm/arm64/bitops.h | 3 ++-
>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
>>>> index 6bf1922680..05045f1109 100644
>>>> --- a/xen/include/asm-arm/arm64/bitops.h
>>>> +++ b/xen/include/asm-arm/arm64/bitops.h
>>>> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
>>>>    
>>>>    static inline int flsl(unsigned long x)
>>>>    {
>>>> -        int ret;
>>>> +        uint64_t ret;
>>>>    
>>>>            if (__builtin_constant_p(x))
>>>>                   return generic_flsl(x);
>>>>    
>>>>            asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
>>>
>>> As x is fixed by the ABI, ret should be unsigned long to match, surely?
>>
>> No need for it. The result of the instruction clz will always be smaller
>> than 64.
>>
>> I suspect they require a 64-bit register just for simplicity as they
>> encode the size for the 2 registers in only a single bit (i.e sf).
>>
>>>
>>> This will compile as it is arm64 specific, but it looks just as wrong
>>> (per the commit message) as using int in the first place.
>> See above. I can clarify it in the commit message.
> 
> I agree with Andrew: I can see that the code is correct, but it really
> looks wrong at first sight. Why not use unsigned long? This is an arm64
> header anyway.

While this is implemented in arm64, this is a function used in common 
code... So the prototype would have to be changed everywhere.

However, as I pointed out this is a design decision from Arm64 and I 
think it would be wrong to return unsigned long.

I offered the suggestion to update the commit message. I can also add a 
comment in the code.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

Hi,

On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It
>> expects the register size to match the value size.
>>
>> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
>> (resp. Arm64) whereas the value is a boolean (Clang consider to be
>> 32-bit).
>>
>> It would be possible to impose 32-bit register for both architecture
>> but this require the code to use __OP32. However, it does not really
>> improve the assembly generated. Instead, replace switch the variable
>> to use register_t.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/include/asm-arm/cpuerrata.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
>> index 55ddfda272..88ef3ca934 100644
>> --- a/xen/include/asm-arm/cpuerrata.h
>> +++ b/xen/include/asm-arm/cpuerrata.h
>> @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)             \
>>           return false;                                           \
>>       else                                                        \
>>       {                                                           \
>> -        bool ret;                                               \
>> +        register_t ret;                                         \
>>                                                                   \
>>           asm volatile (ALTERNATIVE("mov %0, #0",                 \
>>                                     "mov %0, #1",                 \
> 
> This is OK. Could you please also change the return statement below?
> Maybe something like:
> 
>    return unlikely(!!ret);
Why? The compiler will implicitly convert the int to bool. 0 will turn 
to false, all the other will be true.

We actually been actively removing !! when the type is bool (see the 
example in get_paged_frame in common/grant_table.c).

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

Hi,

On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It
>> expects the register size to match the value size.
>>
>> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
>> (resp. Arm64) whereas the value is a boolean (Clang consider to be
>> 32-bit).
>>
>> It would be possible to impose 32-bit register for both architecture
>> but this require the code to use __OP32. However, it does not really
>> improve the assembly generated. Instead, replace switch the variable
>> to use register_t.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/include/asm-arm/cpuerrata.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
>> index 55ddfda272..88ef3ca934 100644
>> --- a/xen/include/asm-arm/cpuerrata.h
>> +++ b/xen/include/asm-arm/cpuerrata.h
>> @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)             \
>>           return false;                                           \
>>       else                                                        \
>>       {                                                           \
>> -        bool ret;                                               \
>> +        register_t ret;                                         \
>>                                                                   \
>>           asm volatile (ALTERNATIVE("mov %0, #0",                 \
>>                                     "mov %0, #1",                 \
> 
> This is OK. Could you please also change the return statement below?
> Maybe something like:
> 
>    return unlikely(!!ret);
Why? The compiler will implicitly convert the int to bool. 0 will turn 
to false, all the other will be true.

We actually been actively removing !! when the type is bool (see the 
example in get_paged_frame in common/grant_table.c).

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 08/12] xen/arm: cpufeature: Match register size with value size in cpus_have_const_cap

[Julien Grall]

On 4/17/19 9:29 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It
>> expects the register size to match the value size.
>>
>> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
>> (resp. Arm64) whereas the value is a boolean (Clang consider to be
>> 32-bit).
>>
>> It would be possible to impose 32-bit register for both architecture
>> but this require the code to use __OP32. However, it does no really
>> improve the assembly generated. Instead, replace switch the variable to
>> use register_t.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/include/asm-arm/cpufeature.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
>> index c2c8f3417c..d06f09ecfa 100644
>> --- a/xen/include/asm-arm/cpufeature.h
>> +++ b/xen/include/asm-arm/cpufeature.h
>> @@ -67,7 +67,7 @@ static inline bool cpus_have_cap(unsigned int num)
>>   
>>   /* System capability check for constant cap */
>>   #define cpus_have_const_cap(num) ({                 \
>> -        bool __ret;                                 \
>> +        register_t __ret;                           \
>>                                                       \
>>           asm volatile (ALTERNATIVE("mov %0, #0",     \
>>                                     "mov %0, #1",     \
> 
> As per the previous one, this is fine, but could you also change the
> last statement below to unlikely(!!__ret);

As per the previous one, the current code is valid. Please justify why 
!! is necessary.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 08/12] xen/arm: cpufeature: Match register size with value size in cpus_have_const_cap

[Julien Grall]

On 4/17/19 9:29 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2019, Julien Grall wrote:
>> Clang is pickier than GCC for the register size in asm statement. It
>> expects the register size to match the value size.
>>
>> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
>> (resp. Arm64) whereas the value is a boolean (Clang consider to be
>> 32-bit).
>>
>> It would be possible to impose 32-bit register for both architecture
>> but this require the code to use __OP32. However, it does no really
>> improve the assembly generated. Instead, replace switch the variable to
>> use register_t.
>>
>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>> ---
>>   xen/include/asm-arm/cpufeature.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
>> index c2c8f3417c..d06f09ecfa 100644
>> --- a/xen/include/asm-arm/cpufeature.h
>> +++ b/xen/include/asm-arm/cpufeature.h
>> @@ -67,7 +67,7 @@ static inline bool cpus_have_cap(unsigned int num)
>>   
>>   /* System capability check for constant cap */
>>   #define cpus_have_const_cap(num) ({                 \
>> -        bool __ret;                                 \
>> +        register_t __ret;                           \
>>                                                       \
>>           asm volatile (ALTERNATIVE("mov %0, #0",     \
>>                                     "mov %0, #1",     \
> 
> As per the previous one, this is fine, but could you also change the
> last statement below to unlikely(!!__ret);

As per the previous one, the current code is valid. Please justify why 
!! is necessary.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hello Julien, Stefano

On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> Hi,
> 
> On 16/04/2019 23:43, Stefano Stabellini wrote:
> > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > Hi Julien,
> > > 
> > > Hi Artem,
> > > 
> > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > Hi all,
> > > > > 
> > > > > This series adds support to build Xen Arm with clang. This series was
> > > > > tested
> > > > > with clang 8.0.
> > > > > 
> > > > > Note that I only did build for arm64. I still need to look at the arm32
> > > > > build.
> > > > > 
> > > > 
> > > > I wonder if you have time to try the series with Arm Compiler 6? I am
> > > > asking because AFAIK it is based on clang/llvm [1] and there's a
> > > > safety-compliant version of it certified by TUV [2]. I don't have a
> > > > license yet so cannot try it myself but maybe you have access.
> > > I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
> > > to pass armclang and the appropriate target option.
> > > 
> > > I also had a linking issue at the end where __2snprintf was not found. It
> > > seems the compiler replace snprintf with __2snprintf, I haven't figured out
> > > why yet.
> > 
> > But after these changes, does it work?
> 
> I haven't tried to fix the linking issues. I only gave a quick try because Artem 
> asked. I have no plan at the moment to go further than that for now.
> 
> Patches are welcomed to add support for armclang.
> 

I have implemented a bunch of HACKs [1] so can build Xen master with
armclang 6.12. Not even "smoke"-tested, just trying to identify missing
parameters and proper linker configuration.

Not yet fixed section placement, lots of warnings from linker like:
Warning: L6170W: Mapping symbol #40 '$x.20' in
.altinstr_replacement(ns16550.o:42) identifies code, but is in a
section not marked as executable.

Also armlink sometimes fails with Internal fault: [0xe81a5a:6120001]


[1] Diff below just for reference with xen master + Julien's clang
patch series applied
---

diff --git a/Config.mk b/Config.mk
index 417039d7f6..0fc84293f9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
+ifneq ($(armds),y)
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
+endif
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
 
 LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i)) 
@@ -234,9 +236,15 @@ endif
 APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
 APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 
-EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
protector-all
+EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+ifeq ($(armds),y)
+EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
+else
+EMBEDDED_EXTRA_CFLAGS += -nopie
+endif
+
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 48c50b5ad7..585d076d4f 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,6 +1,15 @@
 AS         = $(CROSS_COMPILE)as
+AR         = $(CROSS_COMPILE)ar
 LD         = $(CROSS_COMPILE)ld
 ifeq ($(clang),y)
+ifeq ($(armds),y)
+CC         = armclang
+CXX        = armclang
+LD_LTO     = armlink
+LD         = armlink -v
+AS         = armasm
+AR         = armar
+else
 ifneq ($(CROSS_COMPILE),)
 CC         = clang -target $(CROSS_COMPILE:-=)
 CXX        = clang++ -target $(CROSS_COMPILE:-=)
@@ -9,13 +18,13 @@ CC         = clang
 CXX        = clang++
 endif
 LD_LTO     = $(CROSS_COMPILE)llvm-ld
+endif
 else
 CC         = $(CROSS_COMPILE)gcc
 CXX        = $(CROSS_COMPILE)g++
 LD_LTO     = $(CROSS_COMPILE)ld
 endif
 CPP        = $(CC) -E
-AR         = $(CROSS_COMPILE)ar
 RANLIB     = $(CROSS_COMPILE)ranlib
 NM         = $(CROSS_COMPILE)nm
 STRIP      = $(CROSS_COMPILE)strip
diff --git a/config/arm32.mk b/config/arm32.mk
index f95228e3c0..5afed07357 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -4,12 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
 
-# -march= -mcpu=
-
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb:
-CFLAGS += -marm
-
+ifeq ($(armds),y)
+# VE needed
+CFLAGS += --target=arm-arm-none-eabi -march=armv7-a
+else
+CFLAGS += -marm # -march= -mcpu=
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
+endif
 
 IOEMU_CPU_ARCH ?= arm
diff --git a/config/arm64.mk b/config/arm64.mk
index aa45772b61..46b203d384 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
 
+ifeq ($(armds),y)
+# VE needed
+CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-a+nofp+nosimd
+else
 CFLAGS += #-marm -march= -mcpu= etc
-
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
+endif
 
 IOEMU_CPU_ARCH ?= aarch64
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index a151b3f625..72b34451d2 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -76,9 +76,11 @@ AFLAGS-y                += -D__ASSEMBLY__
 # Older clang's built-in assembler doesn't understand .skip with
labels:
 # https://bugs.llvm.org/show_bug.cgi?id=27369
 ifeq ($(clang),y)
+ifneq ($(armds),y)
 $(call as-option-add,CFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",,\
                      -no-integrated-as)
 endif
+endif
 
 ALL_OBJS := $(ALL_OBJS-y)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hello Julien, Stefano

On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> Hi,
> 
> On 16/04/2019 23:43, Stefano Stabellini wrote:
> > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > Hi Julien,
> > > 
> > > Hi Artem,
> > > 
> > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > Hi all,
> > > > > 
> > > > > This series adds support to build Xen Arm with clang. This series was
> > > > > tested
> > > > > with clang 8.0.
> > > > > 
> > > > > Note that I only did build for arm64. I still need to look at the arm32
> > > > > build.
> > > > > 
> > > > 
> > > > I wonder if you have time to try the series with Arm Compiler 6? I am
> > > > asking because AFAIK it is based on clang/llvm [1] and there's a
> > > > safety-compliant version of it certified by TUV [2]. I don't have a
> > > > license yet so cannot try it myself but maybe you have access.
> > > I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
> > > to pass armclang and the appropriate target option.
> > > 
> > > I also had a linking issue at the end where __2snprintf was not found. It
> > > seems the compiler replace snprintf with __2snprintf, I haven't figured out
> > > why yet.
> > 
> > But after these changes, does it work?
> 
> I haven't tried to fix the linking issues. I only gave a quick try because Artem 
> asked. I have no plan at the moment to go further than that for now.
> 
> Patches are welcomed to add support for armclang.
> 

I have implemented a bunch of HACKs [1] so can build Xen master with
armclang 6.12. Not even "smoke"-tested, just trying to identify missing
parameters and proper linker configuration.

Not yet fixed section placement, lots of warnings from linker like:
Warning: L6170W: Mapping symbol #40 '$x.20' in
.altinstr_replacement(ns16550.o:42) identifies code, but is in a
section not marked as executable.

Also armlink sometimes fails with Internal fault: [0xe81a5a:6120001]


[1] Diff below just for reference with xen master + Julien's clang
patch series applied
---

diff --git a/Config.mk b/Config.mk
index 417039d7f6..0fc84293f9 100644
--- a/Config.mk
+++ b/Config.mk
@@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
 
 $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
 $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
+ifneq ($(armds),y)
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
+endif
 $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
 
 LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i)) 
@@ -234,9 +236,15 @@ endif
 APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
 APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 
-EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
protector-all
+EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
+ifeq ($(armds),y)
+EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
+else
+EMBEDDED_EXTRA_CFLAGS += -nopie
+endif
+
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 48c50b5ad7..585d076d4f 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -1,6 +1,15 @@
 AS         = $(CROSS_COMPILE)as
+AR         = $(CROSS_COMPILE)ar
 LD         = $(CROSS_COMPILE)ld
 ifeq ($(clang),y)
+ifeq ($(armds),y)
+CC         = armclang
+CXX        = armclang
+LD_LTO     = armlink
+LD         = armlink -v
+AS         = armasm
+AR         = armar
+else
 ifneq ($(CROSS_COMPILE),)
 CC         = clang -target $(CROSS_COMPILE:-=)
 CXX        = clang++ -target $(CROSS_COMPILE:-=)
@@ -9,13 +18,13 @@ CC         = clang
 CXX        = clang++
 endif
 LD_LTO     = $(CROSS_COMPILE)llvm-ld
+endif
 else
 CC         = $(CROSS_COMPILE)gcc
 CXX        = $(CROSS_COMPILE)g++
 LD_LTO     = $(CROSS_COMPILE)ld
 endif
 CPP        = $(CC) -E
-AR         = $(CROSS_COMPILE)ar
 RANLIB     = $(CROSS_COMPILE)ranlib
 NM         = $(CROSS_COMPILE)nm
 STRIP      = $(CROSS_COMPILE)strip
diff --git a/config/arm32.mk b/config/arm32.mk
index f95228e3c0..5afed07357 100644
--- a/config/arm32.mk
+++ b/config/arm32.mk
@@ -4,12 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
 
-# -march= -mcpu=
-
 # Explicitly specifiy 32-bit ARM ISA since toolchain default can be
-mthumb:
-CFLAGS += -marm
-
+ifeq ($(armds),y)
+# VE needed
+CFLAGS += --target=arm-arm-none-eabi -march=armv7-a
+else
+CFLAGS += -marm # -march= -mcpu=
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
+endif
 
 IOEMU_CPU_ARCH ?= arm
diff --git a/config/arm64.mk b/config/arm64.mk
index aa45772b61..46b203d384 100644
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
 
 CONFIG_XEN_INSTALL_SUFFIX :=
 
+ifeq ($(armds),y)
+# VE needed
+CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-a+nofp+nosimd
+else
 CFLAGS += #-marm -march= -mcpu= etc
-
 # Use only if calling $(LD) directly.
 LDFLAGS_DIRECT += -EL
+endif
 
 IOEMU_CPU_ARCH ?= aarch64
 
diff --git a/xen/Rules.mk b/xen/Rules.mk
index a151b3f625..72b34451d2 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -76,9 +76,11 @@ AFLAGS-y                += -D__ASSEMBLY__
 # Older clang's built-in assembler doesn't understand .skip with
labels:
 # https://bugs.llvm.org/show_bug.cgi?id=27369
 ifeq ($(clang),y)
+ifneq ($(armds),y)
 $(call as-option-add,CFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",,\
                      -no-integrated-as)
 endif
+endif
 
 ALL_OBJS := $(ALL_OBJS-y)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

On 18/04/2019 10:15, Artem Mygaiev wrote:
> Hello Julien, Stefano

Hi Artem,

> On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
>> Hi,
>>
>> On 16/04/2019 23:43, Stefano Stabellini wrote:
>>> On Fri, 29 Mar 2019, Julien Grall wrote:
>>>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>>>> Hi Julien,
>>>>
>>>> Hi Artem,
>>>>
>>>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This series adds support to build Xen Arm with clang. This series was
>>>>>> tested
>>>>>> with clang 8.0.
>>>>>>
>>>>>> Note that I only did build for arm64. I still need to look at the arm32
>>>>>> build.
>>>>>>
>>>>>
>>>>> I wonder if you have time to try the series with Arm Compiler 6? I am
>>>>> asking because AFAIK it is based on clang/llvm [1] and there's a
>>>>> safety-compliant version of it certified by TUV [2]. I don't have a
>>>>> license yet so cannot try it myself but maybe you have access.
>>>> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
>>>> to pass armclang and the appropriate target option.
>>>>
>>>> I also had a linking issue at the end where __2snprintf was not found. It
>>>> seems the compiler replace snprintf with __2snprintf, I haven't figured out
>>>> why yet.
>>>
>>> But after these changes, does it work?
>>
>> I haven't tried to fix the linking issues. I only gave a quick try because Artem
>> asked. I have no plan at the moment to go further than that for now.
>>
>> Patches are welcomed to add support for armclang.
>>
> 
> I have implemented a bunch of HACKs [1] so can build Xen master with
> armclang 6.12. Not even "smoke"-tested, just trying to identify missing
> parameters and proper linker configuration.

Thank you for looking at it. Some comments below.

> 
> Not yet fixed section placement, lots of warnings from linker like:
> Warning: L6170W: Mapping symbol #40 '$x.20' in
> .altinstr_replacement(ns16550.o:42) identifies code, but is in a
> section not marked as executable.

Instruction in the sections .altinstr_replacement are never meant to be executed.

I guess this is coming from armlink? Any particular reason to use armlink and 
not ld as we do on clang?

> 
> Also armlink sometimes fails with Internal fault: [0xe81a5a:6120001]

Do you have more output?

> 
> 
> [1] Diff below just for reference with xen master + Julien's clang
> patch series applied
> ---
> 
> diff --git a/Config.mk b/Config.mk
> index 417039d7f6..0fc84293f9 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
>   
>   $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
>   $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> +ifneq ($(armds),y)
>   $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)

I didn't need this on Arm Compiler 6.11. Can you provide the list of error you 
get here?

> +endif
>   $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
>   
>   LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> @@ -234,9 +236,15 @@ endif
>   APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
>   APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>   
> -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
> protector-all
> +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-protector-all
>   EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
>   
> +ifeq ($(armds),y)
> +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi

Why do you need this? Is it because armlink does not support -nopie?

> +else
> +EMBEDDED_EXTRA_CFLAGS += -nopie
> +endif
> +
>   XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
>   # All the files at that location were downloaded from elsewhere on
>   # the internet.  The original download URL is preserved as a comment
> diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> index 48c50b5ad7..585d076d4f 100644
> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -1,6 +1,15 @@
>   AS         = $(CROSS_COMPILE)as
> +AR         = $(CROSS_COMPILE)ar
>   LD         = $(CROSS_COMPILE)ld
>   ifeq ($(clang),y)
> +ifeq ($(armds),y)
> +CC         = armclang
> +CXX        = armclang
> +LD_LTO     = armlink
> +LD         = armlink -v
> +AS         = armasm
> +AR         = armar
> +else
>   ifneq ($(CROSS_COMPILE),)
>   CC         = clang -target $(CROSS_COMPILE:-=)
>   CXX        = clang++ -target $(CROSS_COMPILE:-=)
> @@ -9,13 +18,13 @@ CC         = clang
>   CXX        = clang++
>   endif
>   LD_LTO     = $(CROSS_COMPILE)llvm-ld
> +endif
>   else
>   CC         = $(CROSS_COMPILE)gcc
>   CXX        = $(CROSS_COMPILE)g++
>   LD_LTO     = $(CROSS_COMPILE)ld
>   endif
>   CPP        = $(CC) -E
> -AR         = $(CROSS_COMPILE)ar
>   RANLIB     = $(CROSS_COMPILE)ranlib
>   NM         = $(CROSS_COMPILE)nm
>   STRIP      = $(CROSS_COMPILE)strip
> diff --git a/config/arm32.mk b/config/arm32.mk
> index f95228e3c0..5afed07357 100644
> --- a/config/arm32.mk
> +++ b/config/arm32.mk
> @@ -4,12 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>   
>   CONFIG_XEN_INSTALL_SUFFIX :=
>   
> -# -march= -mcpu=
> -
>   # Explicitly specifiy 32-bit ARM ISA since toolchain default can be
> -mthumb:
> -CFLAGS += -marm
> -
> +ifeq ($(armds),y)
> +# VE needed
> +CFLAGS += --target=arm-arm-none-eabi -march=armv7-a

-marm should do the right thing even on armclang.

You would still need --target=.... but that's should depend on $CROSS_COMPILE 
(or any other name we decide).

> +else
> +CFLAGS += -marm # -march= -mcpu=
>   # Use only if calling $(LD) directly.
>   LDFLAGS_DIRECT += -EL
> +endif
>   
>   IOEMU_CPU_ARCH ?= arm
> diff --git a/config/arm64.mk b/config/arm64.mk
> index aa45772b61..46b203d384 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>   
>   CONFIG_XEN_INSTALL_SUFFIX :=
>   
> +ifeq ($(armds),y)
> +# VE needed
> +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-a+nofp+nosimd

Same remark for --target.

Also, -march=armv8.1 looks wrong to me because this may generate code that will 
not work on armv8.0 platform.

> +else
>   CFLAGS += #-marm -march= -mcpu= etc
> -
>   # Use only if calling $(LD) directly.
>   LDFLAGS_DIRECT += -EL
> +endif
>   
>   IOEMU_CPU_ARCH ?= aarch64
>   
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index a151b3f625..72b34451d2 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -76,9 +76,11 @@ AFLAGS-y                += -D__ASSEMBLY__
>   # Older clang's built-in assembler doesn't understand .skip with
> labels:
>   # https://bugs.llvm.org/show_bug.cgi?id=27369
>   ifeq ($(clang),y)
> +ifneq ($(armds),y)
>   $(call as-option-add,CFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",,\
>                        -no-integrated-as)
>   endif
> +endif
>   
>   ALL_OBJS := $(ALL_OBJS-y)
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

On 18/04/2019 10:15, Artem Mygaiev wrote:
> Hello Julien, Stefano

Hi Artem,

> On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
>> Hi,
>>
>> On 16/04/2019 23:43, Stefano Stabellini wrote:
>>> On Fri, 29 Mar 2019, Julien Grall wrote:
>>>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>>>> Hi Julien,
>>>>
>>>> Hi Artem,
>>>>
>>>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> This series adds support to build Xen Arm with clang. This series was
>>>>>> tested
>>>>>> with clang 8.0.
>>>>>>
>>>>>> Note that I only did build for arm64. I still need to look at the arm32
>>>>>> build.
>>>>>>
>>>>>
>>>>> I wonder if you have time to try the series with Arm Compiler 6? I am
>>>>> asking because AFAIK it is based on clang/llvm [1] and there's a
>>>>> safety-compliant version of it certified by TUV [2]. I don't have a
>>>>> license yet so cannot try it myself but maybe you have access.
>>>> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
>>>> to pass armclang and the appropriate target option.
>>>>
>>>> I also had a linking issue at the end where __2snprintf was not found. It
>>>> seems the compiler replace snprintf with __2snprintf, I haven't figured out
>>>> why yet.
>>>
>>> But after these changes, does it work?
>>
>> I haven't tried to fix the linking issues. I only gave a quick try because Artem
>> asked. I have no plan at the moment to go further than that for now.
>>
>> Patches are welcomed to add support for armclang.
>>
> 
> I have implemented a bunch of HACKs [1] so can build Xen master with
> armclang 6.12. Not even "smoke"-tested, just trying to identify missing
> parameters and proper linker configuration.

Thank you for looking at it. Some comments below.

> 
> Not yet fixed section placement, lots of warnings from linker like:
> Warning: L6170W: Mapping symbol #40 '$x.20' in
> .altinstr_replacement(ns16550.o:42) identifies code, but is in a
> section not marked as executable.

Instruction in the sections .altinstr_replacement are never meant to be executed.

I guess this is coming from armlink? Any particular reason to use armlink and 
not ld as we do on clang?

> 
> Also armlink sometimes fails with Internal fault: [0xe81a5a:6120001]

Do you have more output?

> 
> 
> [1] Diff below just for reference with xen master + Julien's clang
> patch series applied
> ---
> 
> diff --git a/Config.mk b/Config.mk
> index 417039d7f6..0fc84293f9 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
>   
>   $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-statement)
>   $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> +ifneq ($(armds),y)
>   $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)

I didn't need this on Arm Compiler 6.11. Can you provide the list of error you 
get here?

> +endif
>   $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
>   
>   LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> @@ -234,9 +236,15 @@ endif
>   APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
>   APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>   
> -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
> protector-all
> +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-protector-all
>   EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
>   
> +ifeq ($(armds),y)
> +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi

Why do you need this? Is it because armlink does not support -nopie?

> +else
> +EMBEDDED_EXTRA_CFLAGS += -nopie
> +endif
> +
>   XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
>   # All the files at that location were downloaded from elsewhere on
>   # the internet.  The original download URL is preserved as a comment
> diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> index 48c50b5ad7..585d076d4f 100644
> --- a/config/StdGNU.mk
> +++ b/config/StdGNU.mk
> @@ -1,6 +1,15 @@
>   AS         = $(CROSS_COMPILE)as
> +AR         = $(CROSS_COMPILE)ar
>   LD         = $(CROSS_COMPILE)ld
>   ifeq ($(clang),y)
> +ifeq ($(armds),y)
> +CC         = armclang
> +CXX        = armclang
> +LD_LTO     = armlink
> +LD         = armlink -v
> +AS         = armasm
> +AR         = armar
> +else
>   ifneq ($(CROSS_COMPILE),)
>   CC         = clang -target $(CROSS_COMPILE:-=)
>   CXX        = clang++ -target $(CROSS_COMPILE:-=)
> @@ -9,13 +18,13 @@ CC         = clang
>   CXX        = clang++
>   endif
>   LD_LTO     = $(CROSS_COMPILE)llvm-ld
> +endif
>   else
>   CC         = $(CROSS_COMPILE)gcc
>   CXX        = $(CROSS_COMPILE)g++
>   LD_LTO     = $(CROSS_COMPILE)ld
>   endif
>   CPP        = $(CC) -E
> -AR         = $(CROSS_COMPILE)ar
>   RANLIB     = $(CROSS_COMPILE)ranlib
>   NM         = $(CROSS_COMPILE)nm
>   STRIP      = $(CROSS_COMPILE)strip
> diff --git a/config/arm32.mk b/config/arm32.mk
> index f95228e3c0..5afed07357 100644
> --- a/config/arm32.mk
> +++ b/config/arm32.mk
> @@ -4,12 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>   
>   CONFIG_XEN_INSTALL_SUFFIX :=
>   
> -# -march= -mcpu=
> -
>   # Explicitly specifiy 32-bit ARM ISA since toolchain default can be
> -mthumb:
> -CFLAGS += -marm
> -
> +ifeq ($(armds),y)
> +# VE needed
> +CFLAGS += --target=arm-arm-none-eabi -march=armv7-a

-marm should do the right thing even on armclang.

You would still need --target=.... but that's should depend on $CROSS_COMPILE 
(or any other name we decide).

> +else
> +CFLAGS += -marm # -march= -mcpu=
>   # Use only if calling $(LD) directly.
>   LDFLAGS_DIRECT += -EL
> +endif
>   
>   IOEMU_CPU_ARCH ?= arm
> diff --git a/config/arm64.mk b/config/arm64.mk
> index aa45772b61..46b203d384 100644
> --- a/config/arm64.mk
> +++ b/config/arm64.mk
> @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>   
>   CONFIG_XEN_INSTALL_SUFFIX :=
>   
> +ifeq ($(armds),y)
> +# VE needed
> +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-a+nofp+nosimd

Same remark for --target.

Also, -march=armv8.1 looks wrong to me because this may generate code that will 
not work on armv8.0 platform.

> +else
>   CFLAGS += #-marm -march= -mcpu= etc
> -
>   # Use only if calling $(LD) directly.
>   LDFLAGS_DIRECT += -EL
> +endif
>   
>   IOEMU_CPU_ARCH ?= aarch64
>   
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index a151b3f625..72b34451d2 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -76,9 +76,11 @@ AFLAGS-y                += -D__ASSEMBLY__
>   # Older clang's built-in assembler doesn't understand .skip with
> labels:
>   # https://bugs.llvm.org/show_bug.cgi?id=27369
>   ifeq ($(clang),y)
> +ifneq ($(armds),y)
>   $(call as-option-add,CFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",,\
>                        -no-integrated-as)
>   endif
> +endif
>   
>   ALL_OBJS := $(ALL_OBJS-y)
> 

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi,

On 27/03/2019 18:45, Julien Grall wrote:

Hi,

I have applied the follow patches to my branch next-4.13. I will merge it to 
unstable on the commit moratorium is lifted.

>    xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h
>    xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit
>      helpers
>    xen/arm: guest_walk: Avoid theoritical unitialized value in
>      get_top_bit
>    xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline

I will respin the rest.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi,

On 27/03/2019 18:45, Julien Grall wrote:

Hi,

I have applied the follow patches to my branch next-4.13. I will merge it to 
unstable on the commit moratorium is lifted.

>    xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h
>    xen/arm64: sysreg: Implement the 32-bit helpers using the 64-bit
>      helpers
>    xen/arm: guest_walk: Avoid theoritical unitialized value in
>      get_top_bit
>    xen/arm64: __cmpxchg and __cmpxchg_mb should always be inline

I will respin the rest.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hi Julien

On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> On 18/04/2019 10:15, Artem Mygaiev wrote:
> > Hello Julien, Stefano
> 
> Hi Artem,
> 
> > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > Hi Julien,
> > > > > 
> > > > > Hi Artem,
> > > > > 
> > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > This series adds support to build Xen Arm with clang.
> > > > > > > This series was
> > > > > > > tested
> > > > > > > with clang 8.0.
> > > > > > > 
> > > > > > > Note that I only did build for arm64. I still need to
> > > > > > > look at the arm32
> > > > > > > build.
> > > > > > > 
> > > > > > 
> > > > > > I wonder if you have time to try the series with Arm
> > > > > > Compiler 6? I am
> > > > > > asking because AFAIK it is based on clang/llvm [1] and
> > > > > > there's a
> > > > > > safety-compliant version of it certified by TUV [2]. I
> > > > > > don't have a
> > > > > > license yet so cannot try it myself but maybe you have
> > > > > > access.
> > > > > 
> > > > > I gave a quick try to the Arm Compiler. I had to hack a bit
> > > > > config/StdGNU.mk
> > > > > to pass armclang and the appropriate target option.
> > > > > 
> > > > > I also had a linking issue at the end where __2snprintf was
> > > > > not found. It
> > > > > seems the compiler replace snprintf with __2snprintf, I
> > > > > haven't figured out
> > > > > why yet.
> > > > 
> > > > But after these changes, does it work?
> > > 
> > > I haven't tried to fix the linking issues. I only gave a quick
> > > try because Artem
> > > asked. I have no plan at the moment to go further than that for
> > > now.
> > > 
> > > Patches are welcomed to add support for armclang.
> > > 
> > 
> > I have implemented a bunch of HACKs [1] so can build Xen master
> > with
> > armclang 6.12. Not even "smoke"-tested, just trying to identify
> > missing
> > parameters and proper linker configuration.
> 
> Thank you for looking at it. Some comments below.
> 
> > Not yet fixed section placement, lots of warnings from linker like:
> > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > .altinstr_replacement(ns16550.o:42) identifies code, but is in a
> > section not marked as executable.
> 
> Instruction in the sections .altinstr_replacement are never meant to
> be executed.
> 
> I guess this is coming from armlink? Any particular reason to use
> armlink and 
> not ld as we do on clang?
> 

Yes, armlink has a "Safety-certified" version of it, while ld doesn't,
unfortunately :(

Though I must mention that I do not have access to safety-certified
version of arm compiler suite, it is not public. Thus checking only
against the 30-day trial version of ARM DS 2019-0 which is shipped with
compiler 6.12

> > Also armlink sometimes fails with Internal fault:
> > [0xe81a5a:6120001]
> 
> Do you have more output?

Just opened a ticket in Arm community forums, see details there
including full build log (dont want to spam ml)
https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001

> 
> > 
> > [1] Diff below just for reference with xen master + Julien's clang
> > patch series applied
> > ---
> > 
> > diff --git a/Config.mk b/Config.mk
> > index 417039d7f6..0fc84293f9 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> >   
> >   $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
> > statement)
> >   $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> > +ifneq ($(armds),y)
> >   $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
> 
> I didn't need this on Arm Compiler 6.11. Can you provide the list of
> error you 
> get here?

error: unknown warning option '-Wno-unused-but-set-variable'; did you
mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]

> 
> > +endif
> >   $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
> >   
> >   LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > @@ -234,9 +236,15 @@ endif
> >   APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
> >   APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
> >   
> > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
> > protector-all
> > +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
> > protector-all
> >   EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> >   
> > +ifeq ($(armds),y)
> > +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
> 
> Why do you need this? Is it because armlink does not support -nopie?

Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide, see
[100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]

> 
> > +else
> > +EMBEDDED_EXTRA_CFLAGS += -nopie
> > +endif
> > +
> >   XEN_EXTFILES_URL ?= 
> > http://xenbits.xen.org/xen-extfiles
> > 
> >   # All the files at that location were downloaded from elsewhere
> > on
> >   # the internet.  The original download URL is preserved as a
> > comment
> > diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> > index 48c50b5ad7..585d076d4f 100644
> > --- a/config/StdGNU.mk
> > +++ b/config/StdGNU.mk
> > @@ -1,6 +1,15 @@
> >   AS         = $(CROSS_COMPILE)as
> > +AR         = $(CROSS_COMPILE)ar
> >   LD         = $(CROSS_COMPILE)ld
> >   ifeq ($(clang),y)
> > +ifeq ($(armds),y)
> > +CC         = armclang
> > +CXX        = armclang
> > +LD_LTO     = armlink
> > +LD         = armlink -v
> > +AS         = armasm
> > +AR         = armar
> > +else
> >   ifneq ($(CROSS_COMPILE),)
> >   CC         = clang -target $(CROSS_COMPILE:-=)
> >   CXX        = clang++ -target $(CROSS_COMPILE:-=)
> > @@ -9,13 +18,13 @@ CC         = clang
> >   CXX        = clang++
> >   endif
> >   LD_LTO     = $(CROSS_COMPILE)llvm-ld
> > +endif
> >   else
> >   CC         = $(CROSS_COMPILE)gcc
> >   CXX        = $(CROSS_COMPILE)g++
> >   LD_LTO     = $(CROSS_COMPILE)ld
> >   endif
> >   CPP        = $(CC) -E
> > -AR         = $(CROSS_COMPILE)ar
> >   RANLIB     = $(CROSS_COMPILE)ranlib
> >   NM         = $(CROSS_COMPILE)nm
> >   STRIP      = $(CROSS_COMPILE)strip
> > diff --git a/config/arm32.mk b/config/arm32.mk
> > index f95228e3c0..5afed07357 100644
> > --- a/config/arm32.mk
> > +++ b/config/arm32.mk
> > @@ -4,12 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> >   
> >   CONFIG_XEN_INSTALL_SUFFIX :=
> >   
> > -# -march= -mcpu=
> > -
> >   # Explicitly specifiy 32-bit ARM ISA since toolchain default can
> > be
> > -mthumb:
> > -CFLAGS += -marm
> > -
> > +ifeq ($(armds),y)
> > +# VE needed
> > +CFLAGS += --target=arm-arm-none-eabi -march=armv7-a
> 
> -marm should do the right thing even on armclang.
> 
> You would still need --target=.... but that's should depend on
> $CROSS_COMPILE 
> (or any other name we decide).

You're right, I forgot to mention - have not yet built for Arm32 so
this is not checked. But, according to manual:

For targets in AArch32 state (--target=arm-arm-none-eabi), there is no
default. You must specify either -march (to target an architecture) or
-mcpu (to target a processor).

[100067_0612_00_en page 1-82]

> 
> > +else
> > +CFLAGS += -marm # -march= -mcpu=
> >   # Use only if calling $(LD) directly.
> >   LDFLAGS_DIRECT += -EL
> > +endif
> >   
> >   IOEMU_CPU_ARCH ?= arm
> > diff --git a/config/arm64.mk b/config/arm64.mk
> > index aa45772b61..46b203d384 100644
> > --- a/config/arm64.mk
> > +++ b/config/arm64.mk
> > @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> >   
> >   CONFIG_XEN_INSTALL_SUFFIX :=
> >   
> > +ifeq ($(armds),y)
> > +# VE needed
> > +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
> > a+nofp+nosimd
> 
> Same remark for --target.
> Also, -march=armv8.1 looks wrong to me because this may generate code
> that will 
> not work on armv8.0 platform.
> 

If I don't specify -march this way, it will built:
 1) without some registers, e.g. TTLB0_EL2 support (build fails)
 2) with vfp and simd enabled (linking fails)

According to Arm compiler manual:
---
For targets in AArch64 state (--target=aarch64-arm-none-eabi), unless
you target a particular processor using -mcpu or a particular
architecture using -march, the compiler defaults to -march=armv8-a,
generating generic code for Armv8‑A in AArch64 state.
[100067_0612_00_en page 1-82]
---
You can prevent the use of floating-point instructions or floating-
point registers for targets in AArch64 state with the
-mcpu=name+nofp+nosimd option. Subsequent use of floating-point data
types in this mode is unsupported.
[100067_0612_00_en page 1-93]
---

> 

> > +else
> >   CFLAGS += #-marm -march= -mcpu= etc
> > -
> >   # Use only if calling $(LD) directly.
> >   LDFLAGS_DIRECT += -EL
> > +endif
> >   
> >   IOEMU_CPU_ARCH ?= aarch64
> >   
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index a151b3f625..72b34451d2 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -76,9 +76,11 @@ AFLAGS-y                += -D__ASSEMBLY__
> >   # Older clang's built-in assembler doesn't understand .skip with
> > labels:
> >   # 
> > https://bugs.llvm.org/show_bug.cgi?id=27369
> > 
> >   ifeq ($(clang),y)
> > +ifneq ($(armds),y)
> >   $(call as-option-add,CFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",,\
> >                        -no-integrated-as)
> >   endif
> > +endif
> >   
> >   ALL_OBJS := $(ALL_OBJS-y)
> > 
> 
> Cheers,

[100067_0612_00_en] https://developer.arm.com/docs/100067/latest
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hi Julien

On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> On 18/04/2019 10:15, Artem Mygaiev wrote:
> > Hello Julien, Stefano
> 
> Hi Artem,
> 
> > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > Hi Julien,
> > > > > 
> > > > > Hi Artem,
> > > > > 
> > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > This series adds support to build Xen Arm with clang.
> > > > > > > This series was
> > > > > > > tested
> > > > > > > with clang 8.0.
> > > > > > > 
> > > > > > > Note that I only did build for arm64. I still need to
> > > > > > > look at the arm32
> > > > > > > build.
> > > > > > > 
> > > > > > 
> > > > > > I wonder if you have time to try the series with Arm
> > > > > > Compiler 6? I am
> > > > > > asking because AFAIK it is based on clang/llvm [1] and
> > > > > > there's a
> > > > > > safety-compliant version of it certified by TUV [2]. I
> > > > > > don't have a
> > > > > > license yet so cannot try it myself but maybe you have
> > > > > > access.
> > > > > 
> > > > > I gave a quick try to the Arm Compiler. I had to hack a bit
> > > > > config/StdGNU.mk
> > > > > to pass armclang and the appropriate target option.
> > > > > 
> > > > > I also had a linking issue at the end where __2snprintf was
> > > > > not found. It
> > > > > seems the compiler replace snprintf with __2snprintf, I
> > > > > haven't figured out
> > > > > why yet.
> > > > 
> > > > But after these changes, does it work?
> > > 
> > > I haven't tried to fix the linking issues. I only gave a quick
> > > try because Artem
> > > asked. I have no plan at the moment to go further than that for
> > > now.
> > > 
> > > Patches are welcomed to add support for armclang.
> > > 
> > 
> > I have implemented a bunch of HACKs [1] so can build Xen master
> > with
> > armclang 6.12. Not even "smoke"-tested, just trying to identify
> > missing
> > parameters and proper linker configuration.
> 
> Thank you for looking at it. Some comments below.
> 
> > Not yet fixed section placement, lots of warnings from linker like:
> > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > .altinstr_replacement(ns16550.o:42) identifies code, but is in a
> > section not marked as executable.
> 
> Instruction in the sections .altinstr_replacement are never meant to
> be executed.
> 
> I guess this is coming from armlink? Any particular reason to use
> armlink and 
> not ld as we do on clang?
> 

Yes, armlink has a "Safety-certified" version of it, while ld doesn't,
unfortunately :(

Though I must mention that I do not have access to safety-certified
version of arm compiler suite, it is not public. Thus checking only
against the 30-day trial version of ARM DS 2019-0 which is shipped with
compiler 6.12

> > Also armlink sometimes fails with Internal fault:
> > [0xe81a5a:6120001]
> 
> Do you have more output?

Just opened a ticket in Arm community forums, see details there
including full build log (dont want to spam ml)
https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001

> 
> > 
> > [1] Diff below just for reference with xen master + Julien's clang
> > patch series applied
> > ---
> > 
> > diff --git a/Config.mk b/Config.mk
> > index 417039d7f6..0fc84293f9 100644
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> >   
> >   $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
> > statement)
> >   $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
> > +ifneq ($(armds),y)
> >   $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
> 
> I didn't need this on Arm Compiler 6.11. Can you provide the list of
> error you 
> get here?

error: unknown warning option '-Wno-unused-but-set-variable'; did you
mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]

> 
> > +endif
> >   $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
> >   
> >   LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > @@ -234,9 +236,15 @@ endif
> >   APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
> >   APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
> >   
> > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
> > protector-all
> > +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
> > protector-all
> >   EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> >   
> > +ifeq ($(armds),y)
> > +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
> 
> Why do you need this? Is it because armlink does not support -nopie?

Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide, see
[100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]

> 
> > +else
> > +EMBEDDED_EXTRA_CFLAGS += -nopie
> > +endif
> > +
> >   XEN_EXTFILES_URL ?= 
> > http://xenbits.xen.org/xen-extfiles
> > 
> >   # All the files at that location were downloaded from elsewhere
> > on
> >   # the internet.  The original download URL is preserved as a
> > comment
> > diff --git a/config/StdGNU.mk b/config/StdGNU.mk
> > index 48c50b5ad7..585d076d4f 100644
> > --- a/config/StdGNU.mk
> > +++ b/config/StdGNU.mk
> > @@ -1,6 +1,15 @@
> >   AS         = $(CROSS_COMPILE)as
> > +AR         = $(CROSS_COMPILE)ar
> >   LD         = $(CROSS_COMPILE)ld
> >   ifeq ($(clang),y)
> > +ifeq ($(armds),y)
> > +CC         = armclang
> > +CXX        = armclang
> > +LD_LTO     = armlink
> > +LD         = armlink -v
> > +AS         = armasm
> > +AR         = armar
> > +else
> >   ifneq ($(CROSS_COMPILE),)
> >   CC         = clang -target $(CROSS_COMPILE:-=)
> >   CXX        = clang++ -target $(CROSS_COMPILE:-=)
> > @@ -9,13 +18,13 @@ CC         = clang
> >   CXX        = clang++
> >   endif
> >   LD_LTO     = $(CROSS_COMPILE)llvm-ld
> > +endif
> >   else
> >   CC         = $(CROSS_COMPILE)gcc
> >   CXX        = $(CROSS_COMPILE)g++
> >   LD_LTO     = $(CROSS_COMPILE)ld
> >   endif
> >   CPP        = $(CC) -E
> > -AR         = $(CROSS_COMPILE)ar
> >   RANLIB     = $(CROSS_COMPILE)ranlib
> >   NM         = $(CROSS_COMPILE)nm
> >   STRIP      = $(CROSS_COMPILE)strip
> > diff --git a/config/arm32.mk b/config/arm32.mk
> > index f95228e3c0..5afed07357 100644
> > --- a/config/arm32.mk
> > +++ b/config/arm32.mk
> > @@ -4,12 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> >   
> >   CONFIG_XEN_INSTALL_SUFFIX :=
> >   
> > -# -march= -mcpu=
> > -
> >   # Explicitly specifiy 32-bit ARM ISA since toolchain default can
> > be
> > -mthumb:
> > -CFLAGS += -marm
> > -
> > +ifeq ($(armds),y)
> > +# VE needed
> > +CFLAGS += --target=arm-arm-none-eabi -march=armv7-a
> 
> -marm should do the right thing even on armclang.
> 
> You would still need --target=.... but that's should depend on
> $CROSS_COMPILE 
> (or any other name we decide).

You're right, I forgot to mention - have not yet built for Arm32 so
this is not checked. But, according to manual:

For targets in AArch32 state (--target=arm-arm-none-eabi), there is no
default. You must specify either -march (to target an architecture) or
-mcpu (to target a processor).

[100067_0612_00_en page 1-82]

> 
> > +else
> > +CFLAGS += -marm # -march= -mcpu=
> >   # Use only if calling $(LD) directly.
> >   LDFLAGS_DIRECT += -EL
> > +endif
> >   
> >   IOEMU_CPU_ARCH ?= arm
> > diff --git a/config/arm64.mk b/config/arm64.mk
> > index aa45772b61..46b203d384 100644
> > --- a/config/arm64.mk
> > +++ b/config/arm64.mk
> > @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> >   
> >   CONFIG_XEN_INSTALL_SUFFIX :=
> >   
> > +ifeq ($(armds),y)
> > +# VE needed
> > +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
> > a+nofp+nosimd
> 
> Same remark for --target.
> Also, -march=armv8.1 looks wrong to me because this may generate code
> that will 
> not work on armv8.0 platform.
> 

If I don't specify -march this way, it will built:
 1) without some registers, e.g. TTLB0_EL2 support (build fails)
 2) with vfp and simd enabled (linking fails)

According to Arm compiler manual:
---
For targets in AArch64 state (--target=aarch64-arm-none-eabi), unless
you target a particular processor using -mcpu or a particular
architecture using -march, the compiler defaults to -march=armv8-a,
generating generic code for Armv8‑A in AArch64 state.
[100067_0612_00_en page 1-82]
---
You can prevent the use of floating-point instructions or floating-
point registers for targets in AArch64 state with the
-mcpu=name+nofp+nosimd option. Subsequent use of floating-point data
types in this mode is unsupported.
[100067_0612_00_en page 1-93]
---

> 

> > +else
> >   CFLAGS += #-marm -march= -mcpu= etc
> > -
> >   # Use only if calling $(LD) directly.
> >   LDFLAGS_DIRECT += -EL
> > +endif
> >   
> >   IOEMU_CPU_ARCH ?= aarch64
> >   
> > diff --git a/xen/Rules.mk b/xen/Rules.mk
> > index a151b3f625..72b34451d2 100644
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -76,9 +76,11 @@ AFLAGS-y                += -D__ASSEMBLY__
> >   # Older clang's built-in assembler doesn't understand .skip with
> > labels:
> >   # 
> > https://bugs.llvm.org/show_bug.cgi?id=27369
> > 
> >   ifeq ($(clang),y)
> > +ifneq ($(armds),y)
> >   $(call as-option-add,CFLAGS,CC,".L0:\n.L1:\n.skip (.L1 - .L0)",,\
> >                        -no-integrated-as)
> >   endif
> > +endif
> >   
> >   ALL_OBJS := $(ALL_OBJS-y)
> > 
> 
> Cheers,

[100067_0612_00_en] https://developer.arm.com/docs/100067/latest
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Stefano Stabellini]

On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Clang understands the GCCism in use here, but still complains that sp is
> > > unitialised. In such cases, resort to the older versions of this code,
> > > which directly read sp into the temporary variable.
> > > 
> > > Note that we still keep the GCCism in the default case, as it causes GCC
> > > to create rather better assembly.
> > > 
> > > This is based on the x86 counterpart.
> > 
> > I understand this is based on an existing approach but what about other
> > compilers? I have a suggestion below.
> 
> What if the compiler actually support named registers? Why would we make the
> code less efficient?

It is not my intention to make the code less efficient for other
compilers. However, reading the commit message and the patch I have the
impression that the clang version is more likely to be applicable to
other compilers, compared to the gcc version. More "standard". The
reason is that the clang version only requires asm inline, while the gcc
version requires both asm inline and named registers. For the sake of
getting Xen to compile out of the box with any C compiler, I think it is
best if we default to the less demanding version of the implementation
for unknown compilers.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Stefano Stabellini]

On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Clang understands the GCCism in use here, but still complains that sp is
> > > unitialised. In such cases, resort to the older versions of this code,
> > > which directly read sp into the temporary variable.
> > > 
> > > Note that we still keep the GCCism in the default case, as it causes GCC
> > > to create rather better assembly.
> > > 
> > > This is based on the x86 counterpart.
> > 
> > I understand this is based on an existing approach but what about other
> > compilers? I have a suggestion below.
> 
> What if the compiler actually support named registers? Why would we make the
> code less efficient?

It is not my intention to make the code less efficient for other
compilers. However, reading the commit message and the patch I have the
impression that the clang version is more likely to be applicable to
other compilers, compared to the gcc version. More "standard". The
reason is that the clang version only requires asm inline, while the gcc
version requires both asm inline and named registers. For the sake of
getting Xen to compile out of the box with any C compiler, I think it is
best if we default to the less demanding version of the implementation
for unknown compilers.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Clang is pickier than GCC for the register size in asm statement. It
> > > expects the register size to match the value size.
> > > 
> > > The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> > > (resp. Arm64) whereas the value is a boolean (Clang consider to be
> > > 32-bit).
> > > 
> > > It would be possible to impose 32-bit register for both architecture
> > > but this require the code to use __OP32. However, it does not really
> > > improve the assembly generated. Instead, replace switch the variable
> > > to use register_t.
> > > 
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > ---
> > >   xen/include/asm-arm/cpuerrata.h | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/xen/include/asm-arm/cpuerrata.h
> > > b/xen/include/asm-arm/cpuerrata.h
> > > index 55ddfda272..88ef3ca934 100644
> > > --- a/xen/include/asm-arm/cpuerrata.h
> > > +++ b/xen/include/asm-arm/cpuerrata.h
> > > @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)
> > > \
> > >           return false;                                           \
> > >       else                                                        \
> > >       {                                                           \
> > > -        bool ret;                                               \
> > > +        register_t ret;                                         \
> > >                                                                   \
> > >           asm volatile (ALTERNATIVE("mov %0, #0",                 \
> > >                                     "mov %0, #1",                 \
> > 
> > This is OK. Could you please also change the return statement below?
> > Maybe something like:
> > 
> >    return unlikely(!!ret);
> Why? The compiler will implicitly convert the int to bool. 0 will turn to
> false, all the other will be true.
> 
> We actually been actively removing !! when the type is bool (see the example
> in get_paged_frame in common/grant_table.c).

Really? Too bad, I loved the explicit conversions to bool. This is a
matter of code style, not correctness, so usually I wouldn't care much.
But I went to read MISRA-C to figure out if there are any differences
from that point of view. From Rule 10.3, it looks like it is not
compliant, because they say that:

  bool_t bla = 0;

is not MISRA-C compliant. While:

  int c = 1;
  bool_t bla = c == 0;

is compliant. So, if I read this right:

  return !!ret //compliant
  return ret;  //not compliant

I am not 100% sure though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Clang is pickier than GCC for the register size in asm statement. It
> > > expects the register size to match the value size.
> > > 
> > > The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> > > (resp. Arm64) whereas the value is a boolean (Clang consider to be
> > > 32-bit).
> > > 
> > > It would be possible to impose 32-bit register for both architecture
> > > but this require the code to use __OP32. However, it does not really
> > > improve the assembly generated. Instead, replace switch the variable
> > > to use register_t.
> > > 
> > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > ---
> > >   xen/include/asm-arm/cpuerrata.h | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/xen/include/asm-arm/cpuerrata.h
> > > b/xen/include/asm-arm/cpuerrata.h
> > > index 55ddfda272..88ef3ca934 100644
> > > --- a/xen/include/asm-arm/cpuerrata.h
> > > +++ b/xen/include/asm-arm/cpuerrata.h
> > > @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)
> > > \
> > >           return false;                                           \
> > >       else                                                        \
> > >       {                                                           \
> > > -        bool ret;                                               \
> > > +        register_t ret;                                         \
> > >                                                                   \
> > >           asm volatile (ALTERNATIVE("mov %0, #0",                 \
> > >                                     "mov %0, #1",                 \
> > 
> > This is OK. Could you please also change the return statement below?
> > Maybe something like:
> > 
> >    return unlikely(!!ret);
> Why? The compiler will implicitly convert the int to bool. 0 will turn to
> false, all the other will be true.
> 
> We actually been actively removing !! when the type is bool (see the example
> in get_paged_frame in common/grant_table.c).

Really? Too bad, I loved the explicit conversions to bool. This is a
matter of code style, not correctness, so usually I wouldn't care much.
But I went to read MISRA-C to figure out if there are any differences
from that point of view. From Rule 10.3, it looks like it is not
compliant, because they say that:

  bool_t bla = 0;

is not MISRA-C compliant. While:

  int c = 1;
  bool_t bla = c == 0;

is compliant. So, if I read this right:

  return !!ret //compliant
  return ret;  //not compliant

I am not 100% sure though.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

(+ Roger)

On 18/04/2019 12:15, Artem Mygaiev wrote:
> Hi Julien
> 
> On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
>> On 18/04/2019 10:15, Artem Mygaiev wrote:
>>> Hello Julien, Stefano
>>
>> Hi Artem,
>>
>>> On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 16/04/2019 23:43, Stefano Stabellini wrote:
>>>>> On Fri, 29 Mar 2019, Julien Grall wrote:
>>>>>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>>>>>> Hi Julien,
>>>>>>
>>>>>> Hi Artem,
>>>>>>
>>>>>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This series adds support to build Xen Arm with clang.
>>>>>>>> This series was
>>>>>>>> tested
>>>>>>>> with clang 8.0.
>>>>>>>>
>>>>>>>> Note that I only did build for arm64. I still need to
>>>>>>>> look at the arm32
>>>>>>>> build.
>>>>>>>>
>>>>>>>
>>>>>>> I wonder if you have time to try the series with Arm
>>>>>>> Compiler 6? I am
>>>>>>> asking because AFAIK it is based on clang/llvm [1] and
>>>>>>> there's a
>>>>>>> safety-compliant version of it certified by TUV [2]. I
>>>>>>> don't have a
>>>>>>> license yet so cannot try it myself but maybe you have
>>>>>>> access.
>>>>>>
>>>>>> I gave a quick try to the Arm Compiler. I had to hack a bit
>>>>>> config/StdGNU.mk
>>>>>> to pass armclang and the appropriate target option.
>>>>>>
>>>>>> I also had a linking issue at the end where __2snprintf was
>>>>>> not found. It
>>>>>> seems the compiler replace snprintf with __2snprintf, I
>>>>>> haven't figured out
>>>>>> why yet.
>>>>>
>>>>> But after these changes, does it work?
>>>>
>>>> I haven't tried to fix the linking issues. I only gave a quick
>>>> try because Artem
>>>> asked. I have no plan at the moment to go further than that for
>>>> now.
>>>>
>>>> Patches are welcomed to add support for armclang.
>>>>
>>>
>>> I have implemented a bunch of HACKs [1] so can build Xen master
>>> with
>>> armclang 6.12. Not even "smoke"-tested, just trying to identify
>>> missing
>>> parameters and proper linker configuration.
>>
>> Thank you for looking at it. Some comments below.
>>
>>> Not yet fixed section placement, lots of warnings from linker like:
>>> Warning: L6170W: Mapping symbol #40 '$x.20' in
>>> .altinstr_replacement(ns16550.o:42) identifies code, but is in a
>>> section not marked as executable.
>>
>> Instruction in the sections .altinstr_replacement are never meant to
>> be executed.
>>
>> I guess this is coming from armlink? Any particular reason to use
>> armlink and
>> not ld as we do on clang?
>>
> 
> Yes, armlink has a "Safety-certified" version of it, while ld doesn't,
> unfortunately :(

I am not sure if anyone tried to build Xen other than with ld so far. I have 
CCed Roger who might have a clue whether there are other blocker.

> 
> Though I must mention that I do not have access to safety-certified
> version of arm compiler suite, it is not public. Thus checking only
> against the 30-day trial version of ARM DS 2019-0 which is shipped with
> compiler 6.12

Any step towards armclang is good :). We can look at the safety-certified 
version afterwards.

I don't seem to be able to link with this patch on 6.12:

Loading object built_in.o.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.

I am using the following command line to build:

42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64 clang=y 
armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y

> 
>>> Also armlink sometimes fails with Internal fault:
>>> [0xe81a5a:6120001]
>>
>> Do you have more output?
> 
> Just opened a ticket in Arm community forums, see details there
> including full build log (dont want to spam ml)
> https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001

There are nothing interesting in except a flood of "armclang: warning: Your 
license for feature ds_suite_eval will expire in 29 days".

Let me know how it goes and I can help to resolve it.

> 
>>
>>>
>>> [1] Diff below just for reference with xen master + Julien's clang
>>> patch series applied
>>> ---
>>>
>>> diff --git a/Config.mk b/Config.mk
>>> index 417039d7f6..0fc84293f9 100644
>>> --- a/Config.mk
>>> +++ b/Config.mk
>>> @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
>>>    
>>>    $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
>>> statement)
>>>    $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
>>> +ifneq ($(armds),y)
>>>    $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
>>
>> I didn't need this on Arm Compiler 6.11. Can you provide the list of
>> error you
>> get here?
> 
> error: unknown warning option '-Wno-unused-but-set-variable'; did you
> mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]

But cc-option-add should only add the flag if it is supported by the compiler. 
So it is not supported, how come this option is actually used to compile?

> 
>>
>>> +endif
>>>    $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
>>>    
>>>    LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
>>> @@ -234,9 +236,15 @@ endif
>>>    APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
>>>    APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>>>    
>>> -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
>>> protector-all
>>> +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
>>> protector-all
>>>    EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
>>>    
>>> +ifeq ($(armds),y)
>>> +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
>>
>> Why do you need this? Is it because armlink does not support -nopie?
> 
> Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide, see
> [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]

Hmmm, but the docs says:

"This option is not supported in AArch64 state". So is that a really good 
replacement?

[...]

>> You would still need --target=.... but that's should depend on
>> $CROSS_COMPILE
>> (or any other name we decide).
> 
> You're right, I forgot to mention - have not yet built for Arm32 so
> this is not checked. But, according to manual:
> 
> For targets in AArch32 state (--target=arm-arm-none-eabi), there is no
> default. You must specify either -march (to target an architecture) or
> -mcpu (to target a processor)

We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit that cortex-a15 
is probably not the most suitable). If some options should applied to the tools 
as well, then we need to migrated them to config/arm32.mk.

> 
> [100067_0612_00_en page 1-82]
> 
>>
>>> +else
>>> +CFLAGS += -marm # -march= -mcpu=
>>>    # Use only if calling $(LD) directly.
>>>    LDFLAGS_DIRECT += -EL
>>> +endif
>>>    
>>>    IOEMU_CPU_ARCH ?= arm
>>> diff --git a/config/arm64.mk b/config/arm64.mk
>>> index aa45772b61..46b203d384 100644
>>> --- a/config/arm64.mk
>>> +++ b/config/arm64.mk
>>> @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>>>    
>>>    CONFIG_XEN_INSTALL_SUFFIX :=
>>>    
>>> +ifeq ($(armds),y)
>>> +# VE needed
>>> +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
>>> a+nofp+nosimd
>>
>> Same remark for --target.
>> Also, -march=armv8.1 looks wrong to me because this may generate code
>> that will
>> not work on armv8.0 platform.
>>
> 
> If I don't specify -march this way, it will built:
>   1) without some registers, e.g. TTLB0_EL2 support (build fails)

I guess you mean TTBR0_EL2 here.

Xen is fully Armv8.0 compliant. So if you can't compile Xen with -march=armv8-a 
then this needs to be investigated and be reported.

Looking at the error thrown:

arm64/head.S:399:13: error: expected writable system register or pstate
         msr TTBR0_EL2, x4

This is likely a compiler bug.

>   2) with vfp and simd enabled (linking fails)
> 
> According to Arm compiler manual:
> ---
> For targets in AArch64 state (--target=aarch64-arm-none-eabi), unless
> you target a particular processor using -mcpu or a particular
> architecture using -march, the compiler defaults to -march=armv8-a,
> generating generic code for Armv8‑A in AArch64 state.
> [100067_0612_00_en page 1-82]
> ---
> You can prevent the use of floating-point instructions or floating-
> point registers for targets in AArch64 state with the
> -mcpu=name+nofp+nosimd option. Subsequent use of floating-point data
> types in this mode is unsupported.
> [100067_0612_00_en page 1-93]
> ---

I assume that -mgeneral-regs-only does not work in your case?

Also, it just occurred to me that nofp+nosimd should only be done for the 
hypervisor. For the tools, we can properly build with SIMD. So this will have to 
be moved in xen/arch/arm/Rules.mk.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

(+ Roger)

On 18/04/2019 12:15, Artem Mygaiev wrote:
> Hi Julien
> 
> On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
>> On 18/04/2019 10:15, Artem Mygaiev wrote:
>>> Hello Julien, Stefano
>>
>> Hi Artem,
>>
>>> On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 16/04/2019 23:43, Stefano Stabellini wrote:
>>>>> On Fri, 29 Mar 2019, Julien Grall wrote:
>>>>>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>>>>>> Hi Julien,
>>>>>>
>>>>>> Hi Artem,
>>>>>>
>>>>>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> This series adds support to build Xen Arm with clang.
>>>>>>>> This series was
>>>>>>>> tested
>>>>>>>> with clang 8.0.
>>>>>>>>
>>>>>>>> Note that I only did build for arm64. I still need to
>>>>>>>> look at the arm32
>>>>>>>> build.
>>>>>>>>
>>>>>>>
>>>>>>> I wonder if you have time to try the series with Arm
>>>>>>> Compiler 6? I am
>>>>>>> asking because AFAIK it is based on clang/llvm [1] and
>>>>>>> there's a
>>>>>>> safety-compliant version of it certified by TUV [2]. I
>>>>>>> don't have a
>>>>>>> license yet so cannot try it myself but maybe you have
>>>>>>> access.
>>>>>>
>>>>>> I gave a quick try to the Arm Compiler. I had to hack a bit
>>>>>> config/StdGNU.mk
>>>>>> to pass armclang and the appropriate target option.
>>>>>>
>>>>>> I also had a linking issue at the end where __2snprintf was
>>>>>> not found. It
>>>>>> seems the compiler replace snprintf with __2snprintf, I
>>>>>> haven't figured out
>>>>>> why yet.
>>>>>
>>>>> But after these changes, does it work?
>>>>
>>>> I haven't tried to fix the linking issues. I only gave a quick
>>>> try because Artem
>>>> asked. I have no plan at the moment to go further than that for
>>>> now.
>>>>
>>>> Patches are welcomed to add support for armclang.
>>>>
>>>
>>> I have implemented a bunch of HACKs [1] so can build Xen master
>>> with
>>> armclang 6.12. Not even "smoke"-tested, just trying to identify
>>> missing
>>> parameters and proper linker configuration.
>>
>> Thank you for looking at it. Some comments below.
>>
>>> Not yet fixed section placement, lots of warnings from linker like:
>>> Warning: L6170W: Mapping symbol #40 '$x.20' in
>>> .altinstr_replacement(ns16550.o:42) identifies code, but is in a
>>> section not marked as executable.
>>
>> Instruction in the sections .altinstr_replacement are never meant to
>> be executed.
>>
>> I guess this is coming from armlink? Any particular reason to use
>> armlink and
>> not ld as we do on clang?
>>
> 
> Yes, armlink has a "Safety-certified" version of it, while ld doesn't,
> unfortunately :(

I am not sure if anyone tried to build Xen other than with ld so far. I have 
CCed Roger who might have a clue whether there are other blocker.

> 
> Though I must mention that I do not have access to safety-certified
> version of arm compiler suite, it is not public. Thus checking only
> against the 30-day trial version of ARM DS 2019-0 which is shipped with
> compiler 6.12

Any step towards armclang is good :). We can look at the safety-certified 
version afterwards.

I don't seem to be able to link with this patch on 6.12:

Loading object built_in.o.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.
Error: L6242E: Cannot link object built_in.o as its attributes are incompatible 
with the image attributes.
    ... A64 clashes with SoftVFP.

I am using the following command line to build:

42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64 clang=y 
armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y

> 
>>> Also armlink sometimes fails with Internal fault:
>>> [0xe81a5a:6120001]
>>
>> Do you have more output?
> 
> Just opened a ticket in Arm community forums, see details there
> including full build log (dont want to spam ml)
> https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001

There are nothing interesting in except a flood of "armclang: warning: Your 
license for feature ds_suite_eval will expire in 29 days".

Let me know how it goes and I can help to resolve it.

> 
>>
>>>
>>> [1] Diff below just for reference with xen master + Julien's clang
>>> patch series applied
>>> ---
>>>
>>> diff --git a/Config.mk b/Config.mk
>>> index 417039d7f6..0fc84293f9 100644
>>> --- a/Config.mk
>>> +++ b/Config.mk
>>> @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
>>>    
>>>    $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
>>> statement)
>>>    $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-statement)
>>> +ifneq ($(armds),y)
>>>    $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
>>
>> I didn't need this on Arm Compiler 6.11. Can you provide the list of
>> error you
>> get here?
> 
> error: unknown warning option '-Wno-unused-but-set-variable'; did you
> mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-option]

But cc-option-add should only add the flag if it is supported by the compiler. 
So it is not supported, how come this option is actually used to compile?

> 
>>
>>> +endif
>>>    $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
>>>    
>>>    LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
>>> @@ -234,9 +236,15 @@ endif
>>>    APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
>>>    APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>>>    
>>> -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-
>>> protector-all
>>> +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
>>> protector-all
>>>    EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
>>>    
>>> +ifeq ($(armds),y)
>>> +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
>>
>> Why do you need this? Is it because armlink does not support -nopie?
> 
> Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide, see
> [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]

Hmmm, but the docs says:

"This option is not supported in AArch64 state". So is that a really good 
replacement?

[...]

>> You would still need --target=.... but that's should depend on
>> $CROSS_COMPILE
>> (or any other name we decide).
> 
> You're right, I forgot to mention - have not yet built for Arm32 so
> this is not checked. But, according to manual:
> 
> For targets in AArch32 state (--target=arm-arm-none-eabi), there is no
> default. You must specify either -march (to target an architecture) or
> -mcpu (to target a processor)

We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit that cortex-a15 
is probably not the most suitable). If some options should applied to the tools 
as well, then we need to migrated them to config/arm32.mk.

> 
> [100067_0612_00_en page 1-82]
> 
>>
>>> +else
>>> +CFLAGS += -marm # -march= -mcpu=
>>>    # Use only if calling $(LD) directly.
>>>    LDFLAGS_DIRECT += -EL
>>> +endif
>>>    
>>>    IOEMU_CPU_ARCH ?= arm
>>> diff --git a/config/arm64.mk b/config/arm64.mk
>>> index aa45772b61..46b203d384 100644
>>> --- a/config/arm64.mk
>>> +++ b/config/arm64.mk
>>> @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>>>    
>>>    CONFIG_XEN_INSTALL_SUFFIX :=
>>>    
>>> +ifeq ($(armds),y)
>>> +# VE needed
>>> +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
>>> a+nofp+nosimd
>>
>> Same remark for --target.
>> Also, -march=armv8.1 looks wrong to me because this may generate code
>> that will
>> not work on armv8.0 platform.
>>
> 
> If I don't specify -march this way, it will built:
>   1) without some registers, e.g. TTLB0_EL2 support (build fails)

I guess you mean TTBR0_EL2 here.

Xen is fully Armv8.0 compliant. So if you can't compile Xen with -march=armv8-a 
then this needs to be investigated and be reported.

Looking at the error thrown:

arm64/head.S:399:13: error: expected writable system register or pstate
         msr TTBR0_EL2, x4

This is likely a compiler bug.

>   2) with vfp and simd enabled (linking fails)
> 
> According to Arm compiler manual:
> ---
> For targets in AArch64 state (--target=aarch64-arm-none-eabi), unless
> you target a particular processor using -mcpu or a particular
> architecture using -march, the compiler defaults to -march=armv8-a,
> generating generic code for Armv8‑A in AArch64 state.
> [100067_0612_00_en page 1-82]
> ---
> You can prevent the use of floating-point instructions or floating-
> point registers for targets in AArch64 state with the
> -mcpu=name+nofp+nosimd option. Subsequent use of floating-point data
> types in this mode is unsupported.
> [100067_0612_00_en page 1-93]
> ---

I assume that -mgeneral-regs-only does not work in your case?

Also, it just occurred to me that nofp+nosimd should only be done for the 
hypervisor. For the tools, we can properly build with SIMD. So this will have to 
be moved in xen/arch/arm/Rules.mk.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Stefano Stabellini]

On Wed, 17 Apr 2019, Julien Grall wrote:
> On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 27/03/2019 19:03, Andrew Cooper wrote:
> > > > On 27/03/2019 18:45, Julien Grall wrote:
> > > > > Clang is pickier than GCC for the register size in asm statement. It
> > > > > expects
> > > > > the register size to match the value size.
> > > > > 
> > > > > The instruction clz is expecting the two operands to be the same size
> > > > > (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
> > > > > value, we need to make the destination variable 64-bit as well.
> > > > > 
> > > > > While at it, add a newline before the return statement.
> > > > > 
> > > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > > ---
> > > > >    xen/include/asm-arm/arm64/bitops.h | 3 ++-
> > > > >    1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/xen/include/asm-arm/arm64/bitops.h
> > > > > b/xen/include/asm-arm/arm64/bitops.h
> > > > > index 6bf1922680..05045f1109 100644
> > > > > --- a/xen/include/asm-arm/arm64/bitops.h
> > > > > +++ b/xen/include/asm-arm/arm64/bitops.h
> > > > > @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long
> > > > > __ffs(unsigned long word)
> > > > >       static inline int flsl(unsigned long x)
> > > > >    {
> > > > > -        int ret;
> > > > > +        uint64_t ret;
> > > > >               if (__builtin_constant_p(x))
> > > > >                   return generic_flsl(x);
> > > > >               asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> > > > 
> > > > As x is fixed by the ABI, ret should be unsigned long to match, surely?
> > > 
> > > No need for it. The result of the instruction clz will always be smaller
> > > than 64.
> > > 
> > > I suspect they require a 64-bit register just for simplicity as they
> > > encode the size for the 2 registers in only a single bit (i.e sf).
> > > 
> > > > 
> > > > This will compile as it is arm64 specific, but it looks just as wrong
> > > > (per the commit message) as using int in the first place.
> > > See above. I can clarify it in the commit message.
> > 
> > I agree with Andrew: I can see that the code is correct, but it really
> > looks wrong at first sight. Why not use unsigned long? This is an arm64
> > header anyway.
> 
> While this is implemented in arm64, this is a function used in common code...
> So the prototype would have to be changed everywhere.
> 
> However, as I pointed out this is a design decision from Arm64 and I think it
> would be wrong to return unsigned long.
> 
> I offered the suggestion to update the commit message. I can also add a
> comment in the code.

Reading your reply, I am pretty sure that we are talking about different
things. I agree that we don't want to change the prototype everywhere,
arm32, x86. It would be good to add a comment to the code or the commit
message, I leave it to you.

My suggestion was basically "code style". I only meant the below. To me
it looks nicer because at least the ret var is the same type of the
argument, and it is more immediately obvious that the clz operation is
correct. Not a big deal.

diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
index 6bf1922..44cceb3 100644
--- a/xen/include/asm-arm/arm64/bitops.h
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -34,7 +34,7 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
 
 static inline int flsl(unsigned long x)
 {
-        int ret;
+        unsigned long ret;
 
         if (__builtin_constant_p(x))
                return generic_flsl(x);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Stefano Stabellini]

On Wed, 17 Apr 2019, Julien Grall wrote:
> On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 27/03/2019 19:03, Andrew Cooper wrote:
> > > > On 27/03/2019 18:45, Julien Grall wrote:
> > > > > Clang is pickier than GCC for the register size in asm statement. It
> > > > > expects
> > > > > the register size to match the value size.
> > > > > 
> > > > > The instruction clz is expecting the two operands to be the same size
> > > > > (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
> > > > > value, we need to make the destination variable 64-bit as well.
> > > > > 
> > > > > While at it, add a newline before the return statement.
> > > > > 
> > > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > > ---
> > > > >    xen/include/asm-arm/arm64/bitops.h | 3 ++-
> > > > >    1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/xen/include/asm-arm/arm64/bitops.h
> > > > > b/xen/include/asm-arm/arm64/bitops.h
> > > > > index 6bf1922680..05045f1109 100644
> > > > > --- a/xen/include/asm-arm/arm64/bitops.h
> > > > > +++ b/xen/include/asm-arm/arm64/bitops.h
> > > > > @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long
> > > > > __ffs(unsigned long word)
> > > > >       static inline int flsl(unsigned long x)
> > > > >    {
> > > > > -        int ret;
> > > > > +        uint64_t ret;
> > > > >               if (__builtin_constant_p(x))
> > > > >                   return generic_flsl(x);
> > > > >               asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> > > > 
> > > > As x is fixed by the ABI, ret should be unsigned long to match, surely?
> > > 
> > > No need for it. The result of the instruction clz will always be smaller
> > > than 64.
> > > 
> > > I suspect they require a 64-bit register just for simplicity as they
> > > encode the size for the 2 registers in only a single bit (i.e sf).
> > > 
> > > > 
> > > > This will compile as it is arm64 specific, but it looks just as wrong
> > > > (per the commit message) as using int in the first place.
> > > See above. I can clarify it in the commit message.
> > 
> > I agree with Andrew: I can see that the code is correct, but it really
> > looks wrong at first sight. Why not use unsigned long? This is an arm64
> > header anyway.
> 
> While this is implemented in arm64, this is a function used in common code...
> So the prototype would have to be changed everywhere.
> 
> However, as I pointed out this is a design decision from Arm64 and I think it
> would be wrong to return unsigned long.
> 
> I offered the suggestion to update the commit message. I can also add a
> comment in the code.

Reading your reply, I am pretty sure that we are talking about different
things. I agree that we don't want to change the prototype everywhere,
arm32, x86. It would be good to add a comment to the code or the commit
message, I leave it to you.

My suggestion was basically "code style". I only meant the below. To me
it looks nicer because at least the ret var is the same type of the
argument, and it is more immediately obvious that the clz operation is
correct. Not a big deal.

diff --git a/xen/include/asm-arm/arm64/bitops.h b/xen/include/asm-arm/arm64/bitops.h
index 6bf1922..44cceb3 100644
--- a/xen/include/asm-arm/arm64/bitops.h
+++ b/xen/include/asm-arm/arm64/bitops.h
@@ -34,7 +34,7 @@ static /*__*/always_inline unsigned long __ffs(unsigned long word)
 
 static inline int flsl(unsigned long x)
 {
-        int ret;
+        unsigned long ret;
 
         if (__builtin_constant_p(x))
                return generic_flsl(x);




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

Hi,

On 18/04/2019 19:23, Stefano Stabellini wrote:
> On Wed, 17 Apr 2019, Julien Grall wrote:
>> Hi,
>>
>> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>>>> Clang is pickier than GCC for the register size in asm statement. It
>>>> expects the register size to match the value size.
>>>>
>>>> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
>>>> (resp. Arm64) whereas the value is a boolean (Clang consider to be
>>>> 32-bit).
>>>>
>>>> It would be possible to impose 32-bit register for both architecture
>>>> but this require the code to use __OP32. However, it does not really
>>>> improve the assembly generated. Instead, replace switch the variable
>>>> to use register_t.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    xen/include/asm-arm/cpuerrata.h | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/include/asm-arm/cpuerrata.h
>>>> b/xen/include/asm-arm/cpuerrata.h
>>>> index 55ddfda272..88ef3ca934 100644
>>>> --- a/xen/include/asm-arm/cpuerrata.h
>>>> +++ b/xen/include/asm-arm/cpuerrata.h
>>>> @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)
>>>> \
>>>>            return false;                                           \
>>>>        else                                                        \
>>>>        {                                                           \
>>>> -        bool ret;                                               \
>>>> +        register_t ret;                                         \
>>>>                                                                    \
>>>>            asm volatile (ALTERNATIVE("mov %0, #0",                 \
>>>>                                      "mov %0, #1",                 \
>>>
>>> This is OK. Could you please also change the return statement below?
>>> Maybe something like:
>>>
>>>     return unlikely(!!ret);
>> Why? The compiler will implicitly convert the int to bool. 0 will turn to
>> false, all the other will be true.
>>
>> We actually been actively removing !! when the type is bool (see the example
>> in get_paged_frame in common/grant_table.c).
> 
> Really? Too bad, I loved the explicit conversions to bool. This is a
> matter of code style, not correctness, so usually I wouldn't care much.
> But I went to read MISRA-C to figure out if there are any differences
> from that point of view. From Rule 10.3, it looks like it is not
> compliant, because they say that:
> 
>    bool_t bla = 0;
> 
> is not MISRA-C compliant. While:
> 
>    int c = 1;
>    bool_t bla = c == 0;
> 
> is compliant. So, if I read this right:
> 
>    return !!ret //compliant
>    return ret;  //not compliant
> 
> I am not 100% sure though.

And if you read that rule the following would also be non-compliant

bool is_nonzero(int b)
{
   return b;
}

I know this example is pretty exaggerated but then does it mean the following 
code is also non-compliant?

bool is_nonzero(int b)
{
     if (b)
       return true;
     else
       return false;
}

If it is considered compliant, then it does not make sense.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

Hi,

On 18/04/2019 19:23, Stefano Stabellini wrote:
> On Wed, 17 Apr 2019, Julien Grall wrote:
>> Hi,
>>
>> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>>>> Clang is pickier than GCC for the register size in asm statement. It
>>>> expects the register size to match the value size.
>>>>
>>>> The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
>>>> (resp. Arm64) whereas the value is a boolean (Clang consider to be
>>>> 32-bit).
>>>>
>>>> It would be possible to impose 32-bit register for both architecture
>>>> but this require the code to use __OP32. However, it does not really
>>>> improve the assembly generated. Instead, replace switch the variable
>>>> to use register_t.
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    xen/include/asm-arm/cpuerrata.h | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/xen/include/asm-arm/cpuerrata.h
>>>> b/xen/include/asm-arm/cpuerrata.h
>>>> index 55ddfda272..88ef3ca934 100644
>>>> --- a/xen/include/asm-arm/cpuerrata.h
>>>> +++ b/xen/include/asm-arm/cpuerrata.h
>>>> @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)
>>>> \
>>>>            return false;                                           \
>>>>        else                                                        \
>>>>        {                                                           \
>>>> -        bool ret;                                               \
>>>> +        register_t ret;                                         \
>>>>                                                                    \
>>>>            asm volatile (ALTERNATIVE("mov %0, #0",                 \
>>>>                                      "mov %0, #1",                 \
>>>
>>> This is OK. Could you please also change the return statement below?
>>> Maybe something like:
>>>
>>>     return unlikely(!!ret);
>> Why? The compiler will implicitly convert the int to bool. 0 will turn to
>> false, all the other will be true.
>>
>> We actually been actively removing !! when the type is bool (see the example
>> in get_paged_frame in common/grant_table.c).
> 
> Really? Too bad, I loved the explicit conversions to bool. This is a
> matter of code style, not correctness, so usually I wouldn't care much.
> But I went to read MISRA-C to figure out if there are any differences
> from that point of view. From Rule 10.3, it looks like it is not
> compliant, because they say that:
> 
>    bool_t bla = 0;
> 
> is not MISRA-C compliant. While:
> 
>    int c = 1;
>    bool_t bla = c == 0;
> 
> is compliant. So, if I read this right:
> 
>    return !!ret //compliant
>    return ret;  //not compliant
> 
> I am not 100% sure though.

And if you read that rule the following would also be non-compliant

bool is_nonzero(int b)
{
   return b;
}

I know this example is pretty exaggerated but then does it mean the following 
code is also non-compliant?

bool is_nonzero(int b)
{
     if (b)
       return true;
     else
       return false;
}

If it is considered compliant, then it does not make sense.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Thu, 18 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 18/04/2019 19:23, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Clang is pickier than GCC for the register size in asm statement. It
> > > > > expects the register size to match the value size.
> > > > > 
> > > > > The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> > > > > (resp. Arm64) whereas the value is a boolean (Clang consider to be
> > > > > 32-bit).
> > > > > 
> > > > > It would be possible to impose 32-bit register for both architecture
> > > > > but this require the code to use __OP32. However, it does not really
> > > > > improve the assembly generated. Instead, replace switch the variable
> > > > > to use register_t.
> > > > > 
> > > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > > ---
> > > > >    xen/include/asm-arm/cpuerrata.h | 2 +-
> > > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/xen/include/asm-arm/cpuerrata.h
> > > > > b/xen/include/asm-arm/cpuerrata.h
> > > > > index 55ddfda272..88ef3ca934 100644
> > > > > --- a/xen/include/asm-arm/cpuerrata.h
> > > > > +++ b/xen/include/asm-arm/cpuerrata.h
> > > > > @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)
> > > > > \
> > > > >            return false;                                           \
> > > > >        else                                                        \
> > > > >        {                                                           \
> > > > > -        bool ret;                                               \
> > > > > +        register_t ret;                                         \
> > > > >                                                                    \
> > > > >            asm volatile (ALTERNATIVE("mov %0, #0",                 \
> > > > >                                      "mov %0, #1",                 \
> > > > 
> > > > This is OK. Could you please also change the return statement below?
> > > > Maybe something like:
> > > > 
> > > >     return unlikely(!!ret);
> > > Why? The compiler will implicitly convert the int to bool. 0 will turn to
> > > false, all the other will be true.
> > > 
> > > We actually been actively removing !! when the type is bool (see the
> > > example
> > > in get_paged_frame in common/grant_table.c).
> > 
> > Really? Too bad, I loved the explicit conversions to bool. This is a
> > matter of code style, not correctness, so usually I wouldn't care much.
> > But I went to read MISRA-C to figure out if there are any differences
> > from that point of view. From Rule 10.3, it looks like it is not
> > compliant, because they say that:
> > 
> >    bool_t bla = 0;
> > 
> > is not MISRA-C compliant. While:
> > 
> >    int c = 1;
> >    bool_t bla = c == 0;
> > 
> > is compliant. So, if I read this right:
> > 
> >    return !!ret //compliant
> >    return ret;  //not compliant
> > 
> > I am not 100% sure though.
> 
> And if you read that rule the following would also be non-compliant
> 
> bool is_nonzero(int b)
> {
>   return b;
> }

Yes, I think you are right.


> I know this example is pretty exaggerated but then does it mean the following
> code is also non-compliant?
> 
> bool is_nonzero(int b)
> {
>     if (b)
>       return true;
>     else
>       return false;
> }
> 
> If it is considered compliant, then it does not make sense.

Yes, I think this is not compliant too. Also, from what I have been
told, this example is famous for being one of the most extreme examples
of MISRA-C non-compliance. I think the compliant version would be:

bool is_nonzero(int b)
{
    if (b != 0)
      return true;
    else
      return false;
}

This is also compliant:

bool is_nonzero(int b)
{
    return (b != 0);
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Thu, 18 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 18/04/2019 19:23, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Clang is pickier than GCC for the register size in asm statement. It
> > > > > expects the register size to match the value size.
> > > > > 
> > > > > The asm statement expects a 32-bit (resp. 64-bit) value on Arm32
> > > > > (resp. Arm64) whereas the value is a boolean (Clang consider to be
> > > > > 32-bit).
> > > > > 
> > > > > It would be possible to impose 32-bit register for both architecture
> > > > > but this require the code to use __OP32. However, it does not really
> > > > > improve the assembly generated. Instead, replace switch the variable
> > > > > to use register_t.
> > > > > 
> > > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > > ---
> > > > >    xen/include/asm-arm/cpuerrata.h | 2 +-
> > > > >    1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/xen/include/asm-arm/cpuerrata.h
> > > > > b/xen/include/asm-arm/cpuerrata.h
> > > > > index 55ddfda272..88ef3ca934 100644
> > > > > --- a/xen/include/asm-arm/cpuerrata.h
> > > > > +++ b/xen/include/asm-arm/cpuerrata.h
> > > > > @@ -14,7 +14,7 @@ static inline bool check_workaround_##erratum(void)
> > > > > \
> > > > >            return false;                                           \
> > > > >        else                                                        \
> > > > >        {                                                           \
> > > > > -        bool ret;                                               \
> > > > > +        register_t ret;                                         \
> > > > >                                                                    \
> > > > >            asm volatile (ALTERNATIVE("mov %0, #0",                 \
> > > > >                                      "mov %0, #1",                 \
> > > > 
> > > > This is OK. Could you please also change the return statement below?
> > > > Maybe something like:
> > > > 
> > > >     return unlikely(!!ret);
> > > Why? The compiler will implicitly convert the int to bool. 0 will turn to
> > > false, all the other will be true.
> > > 
> > > We actually been actively removing !! when the type is bool (see the
> > > example
> > > in get_paged_frame in common/grant_table.c).
> > 
> > Really? Too bad, I loved the explicit conversions to bool. This is a
> > matter of code style, not correctness, so usually I wouldn't care much.
> > But I went to read MISRA-C to figure out if there are any differences
> > from that point of view. From Rule 10.3, it looks like it is not
> > compliant, because they say that:
> > 
> >    bool_t bla = 0;
> > 
> > is not MISRA-C compliant. While:
> > 
> >    int c = 1;
> >    bool_t bla = c == 0;
> > 
> > is compliant. So, if I read this right:
> > 
> >    return !!ret //compliant
> >    return ret;  //not compliant
> > 
> > I am not 100% sure though.
> 
> And if you read that rule the following would also be non-compliant
> 
> bool is_nonzero(int b)
> {
>   return b;
> }

Yes, I think you are right.


> I know this example is pretty exaggerated but then does it mean the following
> code is also non-compliant?
> 
> bool is_nonzero(int b)
> {
>     if (b)
>       return true;
>     else
>       return false;
> }
> 
> If it is considered compliant, then it does not make sense.

Yes, I think this is not compliant too. Also, from what I have been
told, this example is famous for being one of the most extreme examples
of MISRA-C non-compliance. I think the compliant version would be:

bool is_nonzero(int b)
{
    if (b != 0)
      return true;
    else
      return false;
}

This is also compliant:

bool is_nonzero(int b)
{
    return (b != 0);
}

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Julien Grall]

Hi,

On 18/04/2019 19:40, Stefano Stabellini wrote:
> On Wed, 17 Apr 2019, Julien Grall wrote:
>> On 4/17/19 9:24 PM, Stefano Stabellini wrote:
>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 27/03/2019 19:03, Andrew Cooper wrote:
>>>>> On 27/03/2019 18:45, Julien Grall wrote:
>>>>>> Clang is pickier than GCC for the register size in asm statement. It
>>>>>> expects
>>>>>> the register size to match the value size.
>>>>>>
>>>>>> The instruction clz is expecting the two operands to be the same size
>>>>>> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
>>>>>> value, we need to make the destination variable 64-bit as well.
>>>>>>
>>>>>> While at it, add a newline before the return statement.
>>>>>>
>>>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>>>> ---
>>>>>>     xen/include/asm-arm/arm64/bitops.h | 3 ++-
>>>>>>     1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/xen/include/asm-arm/arm64/bitops.h
>>>>>> b/xen/include/asm-arm/arm64/bitops.h
>>>>>> index 6bf1922680..05045f1109 100644
>>>>>> --- a/xen/include/asm-arm/arm64/bitops.h
>>>>>> +++ b/xen/include/asm-arm/arm64/bitops.h
>>>>>> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long
>>>>>> __ffs(unsigned long word)
>>>>>>        static inline int flsl(unsigned long x)
>>>>>>     {
>>>>>> -        int ret;
>>>>>> +        uint64_t ret;
>>>>>>                if (__builtin_constant_p(x))
>>>>>>                    return generic_flsl(x);
>>>>>>                asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
>>>>>
>>>>> As x is fixed by the ABI, ret should be unsigned long to match, surely?
>>>>
>>>> No need for it. The result of the instruction clz will always be smaller
>>>> than 64.
>>>>
>>>> I suspect they require a 64-bit register just for simplicity as they
>>>> encode the size for the 2 registers in only a single bit (i.e sf).
>>>>
>>>>>
>>>>> This will compile as it is arm64 specific, but it looks just as wrong
>>>>> (per the commit message) as using int in the first place.
>>>> See above. I can clarify it in the commit message.
>>>
>>> I agree with Andrew: I can see that the code is correct, but it really
>>> looks wrong at first sight. Why not use unsigned long? This is an arm64
>>> header anyway.
>>
>> While this is implemented in arm64, this is a function used in common code...
>> So the prototype would have to be changed everywhere.
>>
>> However, as I pointed out this is a design decision from Arm64 and I think it
>> would be wrong to return unsigned long.
>>
>> I offered the suggestion to update the commit message. I can also add a
>> comment in the code.
> 
> Reading your reply, I am pretty sure that we are talking about different
> things. I agree that we don't want to change the prototype everywhere,
> arm32, x86. It would be good to add a comment to the code or the commit
> message, I leave it to you.
> 
> My suggestion was basically "code style". I only meant the below. To me
> it looks nicer because at least the ret var is the same type of the
> argument, and it is more immediately obvious that the clz operation is
> correct. Not a big deal.

I find quite amusing that you suggest this when in the patch #7 you mention the 
MISRA rule 10.1 which forbid assigning a value to a narrower type (unsigned long 
-> int).

Regardless that, clz operation clearly ask for a 64-bit value. So uint64_t makes 
much more sense than "unsigned long". In general, I am a strong advocate to use 
uintX_t when the size is known. "unsigned long" should only be used in place you 
need compat between 32-bit and 64-bit code.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Julien Grall]

Hi,

On 18/04/2019 19:40, Stefano Stabellini wrote:
> On Wed, 17 Apr 2019, Julien Grall wrote:
>> On 4/17/19 9:24 PM, Stefano Stabellini wrote:
>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>>>> Hi,
>>>>
>>>> On 27/03/2019 19:03, Andrew Cooper wrote:
>>>>> On 27/03/2019 18:45, Julien Grall wrote:
>>>>>> Clang is pickier than GCC for the register size in asm statement. It
>>>>>> expects
>>>>>> the register size to match the value size.
>>>>>>
>>>>>> The instruction clz is expecting the two operands to be the same size
>>>>>> (i.e 32-bit or 64-bit). As the flsl function is dealing with 64-bit
>>>>>> value, we need to make the destination variable 64-bit as well.
>>>>>>
>>>>>> While at it, add a newline before the return statement.
>>>>>>
>>>>>> Signed-off-by: Julien Grall <julien.grall@arm.com>
>>>>>> ---
>>>>>>     xen/include/asm-arm/arm64/bitops.h | 3 ++-
>>>>>>     1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/xen/include/asm-arm/arm64/bitops.h
>>>>>> b/xen/include/asm-arm/arm64/bitops.h
>>>>>> index 6bf1922680..05045f1109 100644
>>>>>> --- a/xen/include/asm-arm/arm64/bitops.h
>>>>>> +++ b/xen/include/asm-arm/arm64/bitops.h
>>>>>> @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long
>>>>>> __ffs(unsigned long word)
>>>>>>        static inline int flsl(unsigned long x)
>>>>>>     {
>>>>>> -        int ret;
>>>>>> +        uint64_t ret;
>>>>>>                if (__builtin_constant_p(x))
>>>>>>                    return generic_flsl(x);
>>>>>>                asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
>>>>>
>>>>> As x is fixed by the ABI, ret should be unsigned long to match, surely?
>>>>
>>>> No need for it. The result of the instruction clz will always be smaller
>>>> than 64.
>>>>
>>>> I suspect they require a 64-bit register just for simplicity as they
>>>> encode the size for the 2 registers in only a single bit (i.e sf).
>>>>
>>>>>
>>>>> This will compile as it is arm64 specific, but it looks just as wrong
>>>>> (per the commit message) as using int in the first place.
>>>> See above. I can clarify it in the commit message.
>>>
>>> I agree with Andrew: I can see that the code is correct, but it really
>>> looks wrong at first sight. Why not use unsigned long? This is an arm64
>>> header anyway.
>>
>> While this is implemented in arm64, this is a function used in common code...
>> So the prototype would have to be changed everywhere.
>>
>> However, as I pointed out this is a design decision from Arm64 and I think it
>> would be wrong to return unsigned long.
>>
>> I offered the suggestion to update the commit message. I can also add a
>> comment in the code.
> 
> Reading your reply, I am pretty sure that we are talking about different
> things. I agree that we don't want to change the prototype everywhere,
> arm32, x86. It would be good to add a comment to the code or the commit
> message, I leave it to you.
> 
> My suggestion was basically "code style". I only meant the below. To me
> it looks nicer because at least the ret var is the same type of the
> argument, and it is more immediately obvious that the clz operation is
> correct. Not a big deal.

I find quite amusing that you suggest this when in the patch #7 you mention the 
MISRA rule 10.1 which forbid assigning a value to a narrower type (unsigned long 
-> int).

Regardless that, clz operation clearly ask for a 64-bit value. So uint64_t makes 
much more sense than "unsigned long". In general, I am a strong advocate to use 
uintX_t when the size is known. "unsigned long" should only be used in place you 
need compat between 32-bit and 64-bit code.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Stefano Stabellini]

On Thu, 18 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 18/04/2019 19:40, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 27/03/2019 19:03, Andrew Cooper wrote:
> > > > > > On 27/03/2019 18:45, Julien Grall wrote:
> > > > > > > Clang is pickier than GCC for the register size in asm statement.
> > > > > > > It
> > > > > > > expects
> > > > > > > the register size to match the value size.
> > > > > > > 
> > > > > > > The instruction clz is expecting the two operands to be the same
> > > > > > > size
> > > > > > > (i.e 32-bit or 64-bit). As the flsl function is dealing with
> > > > > > > 64-bit
> > > > > > > value, we need to make the destination variable 64-bit as well.
> > > > > > > 
> > > > > > > While at it, add a newline before the return statement.
> > > > > > > 
> > > > > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > > > > ---
> > > > > > >     xen/include/asm-arm/arm64/bitops.h | 3 ++-
> > > > > > >     1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/xen/include/asm-arm/arm64/bitops.h
> > > > > > > b/xen/include/asm-arm/arm64/bitops.h
> > > > > > > index 6bf1922680..05045f1109 100644
> > > > > > > --- a/xen/include/asm-arm/arm64/bitops.h
> > > > > > > +++ b/xen/include/asm-arm/arm64/bitops.h
> > > > > > > @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long
> > > > > > > __ffs(unsigned long word)
> > > > > > >        static inline int flsl(unsigned long x)
> > > > > > >     {
> > > > > > > -        int ret;
> > > > > > > +        uint64_t ret;
> > > > > > >                if (__builtin_constant_p(x))
> > > > > > >                    return generic_flsl(x);
> > > > > > >                asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> > > > > > 
> > > > > > As x is fixed by the ABI, ret should be unsigned long to match,
> > > > > > surely?
> > > > > 
> > > > > No need for it. The result of the instruction clz will always be
> > > > > smaller
> > > > > than 64.
> > > > > 
> > > > > I suspect they require a 64-bit register just for simplicity as they
> > > > > encode the size for the 2 registers in only a single bit (i.e sf).
> > > > > 
> > > > > > 
> > > > > > This will compile as it is arm64 specific, but it looks just as
> > > > > > wrong
> > > > > > (per the commit message) as using int in the first place.
> > > > > See above. I can clarify it in the commit message.
> > > > 
> > > > I agree with Andrew: I can see that the code is correct, but it really
> > > > looks wrong at first sight. Why not use unsigned long? This is an arm64
> > > > header anyway.
> > > 
> > > While this is implemented in arm64, this is a function used in common
> > > code...
> > > So the prototype would have to be changed everywhere.
> > > 
> > > However, as I pointed out this is a design decision from Arm64 and I think
> > > it
> > > would be wrong to return unsigned long.
> > > 
> > > I offered the suggestion to update the commit message. I can also add a
> > > comment in the code.
> > 
> > Reading your reply, I am pretty sure that we are talking about different
> > things. I agree that we don't want to change the prototype everywhere,
> > arm32, x86. It would be good to add a comment to the code or the commit
> > message, I leave it to you.
> > 
> > My suggestion was basically "code style". I only meant the below. To me
> > it looks nicer because at least the ret var is the same type of the
> > argument, and it is more immediately obvious that the clz operation is
> > correct. Not a big deal.
> 
> I find quite amusing that you suggest this when in the patch #7 you mention
> the MISRA rule 10.1 which forbid assigning a value to a narrower type
> (unsigned long -> int).
> 
> Regardless that, clz operation clearly ask for a 64-bit value. So uint64_t
> makes much more sense than "unsigned long". In general, I am a strong advocate
> to use uintX_t when the size is known. "unsigned long" should only be used in
> place you need compat between 32-bit and 64-bit code.

all right, OK by me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 05/12] xen/arm64: bitops: Match the register size with the value size in flsl

[Stefano Stabellini]

On Thu, 18 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 18/04/2019 19:40, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 27/03/2019 19:03, Andrew Cooper wrote:
> > > > > > On 27/03/2019 18:45, Julien Grall wrote:
> > > > > > > Clang is pickier than GCC for the register size in asm statement.
> > > > > > > It
> > > > > > > expects
> > > > > > > the register size to match the value size.
> > > > > > > 
> > > > > > > The instruction clz is expecting the two operands to be the same
> > > > > > > size
> > > > > > > (i.e 32-bit or 64-bit). As the flsl function is dealing with
> > > > > > > 64-bit
> > > > > > > value, we need to make the destination variable 64-bit as well.
> > > > > > > 
> > > > > > > While at it, add a newline before the return statement.
> > > > > > > 
> > > > > > > Signed-off-by: Julien Grall <julien.grall@arm.com>
> > > > > > > ---
> > > > > > >     xen/include/asm-arm/arm64/bitops.h | 3 ++-
> > > > > > >     1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/xen/include/asm-arm/arm64/bitops.h
> > > > > > > b/xen/include/asm-arm/arm64/bitops.h
> > > > > > > index 6bf1922680..05045f1109 100644
> > > > > > > --- a/xen/include/asm-arm/arm64/bitops.h
> > > > > > > +++ b/xen/include/asm-arm/arm64/bitops.h
> > > > > > > @@ -34,12 +34,13 @@ static /*__*/always_inline unsigned long
> > > > > > > __ffs(unsigned long word)
> > > > > > >        static inline int flsl(unsigned long x)
> > > > > > >     {
> > > > > > > -        int ret;
> > > > > > > +        uint64_t ret;
> > > > > > >                if (__builtin_constant_p(x))
> > > > > > >                    return generic_flsl(x);
> > > > > > >                asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> > > > > > 
> > > > > > As x is fixed by the ABI, ret should be unsigned long to match,
> > > > > > surely?
> > > > > 
> > > > > No need for it. The result of the instruction clz will always be
> > > > > smaller
> > > > > than 64.
> > > > > 
> > > > > I suspect they require a 64-bit register just for simplicity as they
> > > > > encode the size for the 2 registers in only a single bit (i.e sf).
> > > > > 
> > > > > > 
> > > > > > This will compile as it is arm64 specific, but it looks just as
> > > > > > wrong
> > > > > > (per the commit message) as using int in the first place.
> > > > > See above. I can clarify it in the commit message.
> > > > 
> > > > I agree with Andrew: I can see that the code is correct, but it really
> > > > looks wrong at first sight. Why not use unsigned long? This is an arm64
> > > > header anyway.
> > > 
> > > While this is implemented in arm64, this is a function used in common
> > > code...
> > > So the prototype would have to be changed everywhere.
> > > 
> > > However, as I pointed out this is a design decision from Arm64 and I think
> > > it
> > > would be wrong to return unsigned long.
> > > 
> > > I offered the suggestion to update the commit message. I can also add a
> > > comment in the code.
> > 
> > Reading your reply, I am pretty sure that we are talking about different
> > things. I agree that we don't want to change the prototype everywhere,
> > arm32, x86. It would be good to add a comment to the code or the commit
> > message, I leave it to you.
> > 
> > My suggestion was basically "code style". I only meant the below. To me
> > it looks nicer because at least the ret var is the same type of the
> > argument, and it is more immediately obvious that the clz operation is
> > correct. Not a big deal.
> 
> I find quite amusing that you suggest this when in the patch #7 you mention
> the MISRA rule 10.1 which forbid assigning a value to a narrower type
> (unsigned long -> int).
> 
> Regardless that, clz operation clearly ask for a 64-bit value. So uint64_t
> makes much more sense than "unsigned long". In general, I am a strong advocate
> to use uintX_t when the size is known. "unsigned long" should only be used in
> place you need compat between 32-bit and 64-bit code.

all right, OK by me

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

On 18/04/2019 19:52, Stefano Stabellini wrote:
> On Thu, 18 Apr 2019, Julien Grall wrote:
>> On 18/04/2019 19:23, Stefano Stabellini wrote:
>>> On Wed, 17 Apr 2019, Julien Grall wrote:
>>>> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
>>>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>> If it is considered compliant, then it does not make sense.
> 
> Yes, I think this is not compliant too. Also, from what I have been
> told, this example is famous for being one of the most extreme examples
> of MISRA-C non-compliance. I think the compliant version would be:
> 
> bool is_nonzero(int b)
> {
>      if (b != 0)
>        return true;
>      else
>        return false;
> }
> 
> This is also compliant:
> 
> bool is_nonzero(int b)
> {
>      return (b != 0);
> }
> 

I will use !!b here and in the next patch. But I still doubt you will be able to 
enforce it in Xen. if ( n ) is quite a common pattern.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Julien Grall]

On 18/04/2019 19:52, Stefano Stabellini wrote:
> On Thu, 18 Apr 2019, Julien Grall wrote:
>> On 18/04/2019 19:23, Stefano Stabellini wrote:
>>> On Wed, 17 Apr 2019, Julien Grall wrote:
>>>> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
>>>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>> If it is considered compliant, then it does not make sense.
> 
> Yes, I think this is not compliant too. Also, from what I have been
> told, this example is famous for being one of the most extreme examples
> of MISRA-C non-compliance. I think the compliant version would be:
> 
> bool is_nonzero(int b)
> {
>      if (b != 0)
>        return true;
>      else
>        return false;
> }
> 
> This is also compliant:
> 
> bool is_nonzero(int b)
> {
>      return (b != 0);
> }
> 

I will use !!b here and in the next patch. But I still doubt you will be able to 
enforce it in Xen. if ( n ) is quite a common pattern.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Thu, 18 Apr 2019, Julien Grall wrote:
> On 18/04/2019 19:52, Stefano Stabellini wrote:
> > On Thu, 18 Apr 2019, Julien Grall wrote:
> > > On 18/04/2019 19:23, Stefano Stabellini wrote:
> > > > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > > > On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > > > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > If it is considered compliant, then it does not make sense.
> > 
> > Yes, I think this is not compliant too. Also, from what I have been
> > told, this example is famous for being one of the most extreme examples
> > of MISRA-C non-compliance. I think the compliant version would be:
> > 
> > bool is_nonzero(int b)
> > {
> >      if (b != 0)
> >        return true;
> >      else
> >        return false;
> > }
> > 
> > This is also compliant:
> > 
> > bool is_nonzero(int b)
> > {
> >      return (b != 0);
> > }
> > 
> 
> I will use !!b here and in the next patch. But I still doubt you will be able
> to enforce it in Xen. if ( n ) is quite a common pattern.
 
Thanks. Baby steps :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 07/12] xen/arm: cpuerrata: Match register size with value size in check_workaround_*

[Stefano Stabellini]

On Thu, 18 Apr 2019, Julien Grall wrote:
> On 18/04/2019 19:52, Stefano Stabellini wrote:
> > On Thu, 18 Apr 2019, Julien Grall wrote:
> > > On 18/04/2019 19:23, Stefano Stabellini wrote:
> > > > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > > > On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > > > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > If it is considered compliant, then it does not make sense.
> > 
> > Yes, I think this is not compliant too. Also, from what I have been
> > told, this example is famous for being one of the most extreme examples
> > of MISRA-C non-compliance. I think the compliant version would be:
> > 
> > bool is_nonzero(int b)
> > {
> >      if (b != 0)
> >        return true;
> >      else
> >        return false;
> > }
> > 
> > This is also compliant:
> > 
> > bool is_nonzero(int b)
> > {
> >      return (b != 0);
> > }
> > 
> 
> I will use !!b here and in the next patch. But I still doubt you will be able
> to enforce it in Xen. if ( n ) is quite a common pattern.
 
Thanks. Baby steps :-)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Stefano Stabellini]

On Fri, 29 Mar 2019, Jan Beulich wrote:
> >>> On 29.03.19 at 10:41, <julien.grall@arm.com> wrote:
> > On 28/03/2019 09:55, Jan Beulich wrote:
> >>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
> >>> Clang uses "-target" option for cross-compilation.
> >> 
> >>> --- a/config/StdGNU.mk
> >>> +++ b/config/StdGNU.mk
> >>> @@ -1,8 +1,13 @@
> >>>   AS         = $(CROSS_COMPILE)as
> >>>   LD         = $(CROSS_COMPILE)ld
> >>>   ifeq ($(clang),y)
> >>> -CC         = $(CROSS_COMPILE)clang
> >>> -CXX        = $(CROSS_COMPILE)clang++
> >>> +ifneq ($(CROSS_COMPILE),)
> >>> +CC         = clang -target $(CROSS_COMPILE:-=)
> >>> +CXX        = clang++ -target $(CROSS_COMPILE:-=)
> >> 
> >> Is dropping dashes from the variable uniformly correct? If so,
> >> could you please clarify in the commit message why that is?
> > The target option requires the following format:
> > 
> > <arch><sub>-<vendor>-<sys>-<abi>
> > 
> > In other places, we need the trailing dash as GNU tools are using the same 
> > format as above with a dash to separate the tool name.
> 
> Oh, I'm sorry - I keep forgetting that the substitution form you
> use only fiddles with trailing dashes. Of course I won't insist, but
> I'd prefer the more obvious $(patsubst %-,%,$(CROSS_COMPILE))
> to be used instead, despite realizing that it's meaningfully longer.

Either way to do variable manipulation is OK, but it would be good to
add Julien's explanation of the -target expected format in the commit
message. I don't have any other comments on this patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 01/12] xen: clang: Support correctly cross-compile

[Stefano Stabellini]

On Fri, 29 Mar 2019, Jan Beulich wrote:
> >>> On 29.03.19 at 10:41, <julien.grall@arm.com> wrote:
> > On 28/03/2019 09:55, Jan Beulich wrote:
> >>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
> >>> Clang uses "-target" option for cross-compilation.
> >> 
> >>> --- a/config/StdGNU.mk
> >>> +++ b/config/StdGNU.mk
> >>> @@ -1,8 +1,13 @@
> >>>   AS         = $(CROSS_COMPILE)as
> >>>   LD         = $(CROSS_COMPILE)ld
> >>>   ifeq ($(clang),y)
> >>> -CC         = $(CROSS_COMPILE)clang
> >>> -CXX        = $(CROSS_COMPILE)clang++
> >>> +ifneq ($(CROSS_COMPILE),)
> >>> +CC         = clang -target $(CROSS_COMPILE:-=)
> >>> +CXX        = clang++ -target $(CROSS_COMPILE:-=)
> >> 
> >> Is dropping dashes from the variable uniformly correct? If so,
> >> could you please clarify in the commit message why that is?
> > The target option requires the following format:
> > 
> > <arch><sub>-<vendor>-<sys>-<abi>
> > 
> > In other places, we need the trailing dash as GNU tools are using the same 
> > format as above with a dash to separate the tool name.
> 
> Oh, I'm sorry - I keep forgetting that the substitution form you
> use only fiddles with trailing dashes. Of course I won't insist, but
> I'd prefer the more obvious $(patsubst %-,%,$(CROSS_COMPILE))
> to be used instead, despite realizing that it's meaningfully longer.

Either way to do variable manipulation is OK, but it would be good to
add Julien's explanation of the -target expected format in the commit
message. I don't have any other comments on this patch.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hello Julien, Roger

On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
> (+ Roger)
> 
> On 18/04/2019 12:15, Artem Mygaiev wrote:
> > Hi Julien
> > 
> > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > Hello Julien, Stefano
> > > 
> > > Hi Artem,
> > > 
> > > > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > > > Hi Julien,
> > > > > > > 
> > > > > > > Hi Artem,
> > > > > > > 
> > > > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > This series adds support to build Xen Arm with clang.
> > > > > > > > > This series was
> > > > > > > > > tested
> > > > > > > > > with clang 8.0.
> > > > > > > > > 
> > > > > > > > > Note that I only did build for arm64. I still need to
> > > > > > > > > look at the arm32
> > > > > > > > > build.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I wonder if you have time to try the series with Arm
> > > > > > > > Compiler 6? I am
> > > > > > > > asking because AFAIK it is based on clang/llvm [1] and
> > > > > > > > there's a
> > > > > > > > safety-compliant version of it certified by TUV [2]. I
> > > > > > > > don't have a
> > > > > > > > license yet so cannot try it myself but maybe you have
> > > > > > > > access.
> > > > > > > 
> > > > > > > I gave a quick try to the Arm Compiler. I had to hack a
> > > > > > > bit
> > > > > > > config/StdGNU.mk
> > > > > > > to pass armclang and the appropriate target option.
> > > > > > > 
> > > > > > > I also had a linking issue at the end where __2snprintf
> > > > > > > was
> > > > > > > not found. It
> > > > > > > seems the compiler replace snprintf with __2snprintf, I
> > > > > > > haven't figured out
> > > > > > > why yet.
> > > > > > 
> > > > > > But after these changes, does it work?
> > > > > 
> > > > > I haven't tried to fix the linking issues. I only gave a
> > > > > quick
> > > > > try because Artem
> > > > > asked. I have no plan at the moment to go further than that
> > > > > for
> > > > > now.
> > > > > 
> > > > > Patches are welcomed to add support for armclang.
> > > > > 
> > > > 
> > > > I have implemented a bunch of HACKs [1] so can build Xen master
> > > > with
> > > > armclang 6.12. Not even "smoke"-tested, just trying to identify
> > > > missing
> > > > parameters and proper linker configuration.
> > > 
> > > Thank you for looking at it. Some comments below.
> > > 
> > > > Not yet fixed section placement, lots of warnings from linker
> > > > like:
> > > > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > > > .altinstr_replacement(ns16550.o:42) identifies code, but is in
> > > > a
> > > > section not marked as executable.
> > > 
> > > Instruction in the sections .altinstr_replacement are never meant
> > > to
> > > be executed.
> > > 
> > > I guess this is coming from armlink? Any particular reason to use
> > > armlink and
> > > not ld as we do on clang?
> > > 
> > 
> > Yes, armlink has a "Safety-certified" version of it, while ld
> > doesn't,
> > unfortunately :(
> 
> I am not sure if anyone tried to build Xen other than with ld so far.
> I have 
> CCed Roger who might have a clue whether there are other blocker.
> 

Looking forward to hearing from Roger.

> > Though I must mention that I do not have access to safety-certified
> > version of arm compiler suite, it is not public. Thus checking only
> > against the 30-day trial version of ARM DS 2019-0 which is shipped
> > with
> > compiler 6.12
> 
> Any step towards armclang is good :). We can look at the safety-
> certified 
> version afterwards.
> 
> I don't seem to be able to link with this patch on 6.12:
> 
> Loading object built_in.o.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> 
> I am using the following command line to build:
> 
> 42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64
> clang=y 
> armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y
> 

I am still struggling with linker internal fault, not sure what changed
in my environment so it started to fail.

> > > > Also armlink sometimes fails with Internal fault:
> > > > [0xe81a5a:6120001]
> > > 
> > > Do you have more output?
> > 
> > Just opened a ticket in Arm community forums, see details there
> > including full build log (dont want to spam ml)
> > https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001
> > 
> 
> There are nothing interesting in except a flood of "armclang:
> warning: Your 
> license for feature ds_suite_eval will expire in 29 days".
> 
> Let me know how it goes and I can help to resolve it.
> 

This is because of the "free" evaluation license I have, probably can
be safely ignored. So far no reaction on my initial post in Arm
Community.

Playing with linker options I found that the error is caused by the use
of "partial linking model" which is enabled by --partial that
correspond to -r in Xen Makefiles, which is not documented but has
similar effect.

> > > > [1] Diff below just for reference with xen master + Julien's
> > > > clang
> > > > patch series applied
> > > > ---
> > > > 
> > > > diff --git a/Config.mk b/Config.mk
> > > > index 417039d7f6..0fc84293f9 100644
> > > > --- a/Config.mk
> > > > +++ b/Config.mk
> > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> > > >    
> > > >    $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
> > > > statement)
> > > >    $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-
> > > > statement)
> > > > +ifneq ($(armds),y)
> > > >    $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
> > > 
> > > I didn't need this on Arm Compiler 6.11. Can you provide the list
> > > of
> > > error you
> > > get here?
> > 
> > error: unknown warning option '-Wno-unused-but-set-variable'; did
> > you
> > mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-
> > option]
> 
> But cc-option-add should only add the flag if it is supported by the
> compiler. 
> So it is not supported, how come this option is actually used to
> compile?
> 

Because the idea of supported option detection rely on the fact that
compiler will throw an error or warning when makefile try and use the
option being tested, but armclang does not even try to check that and
failing with
  armclang: fatal error: no target architecture given; use --
target=arm-arm-none-eabi or --target=aarch64-arm-none-eabi
and thus cc-option-add does not detect unsupported options

> > > > +endif
> > > >    $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
> > > >    
> > > >    LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > > > @@ -234,9 +236,15 @@ endif
> > > >    APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
> > > >    APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
> > > >    
> > > > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-
> > > > stack-
> > > > protector-all
> > > > +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
> > > > protector-all
> > > >    EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> > > >    
> > > > +ifeq ($(armds),y)
> > > > +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
> > > 
> > > Why do you need this? Is it because armlink does not support
> > > -nopie?
> > 
> > Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide,
> > see
> > [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]
> 
> Hmmm, but the docs says:
> 
> "This option is not supported in AArch64 state". So is that a really
> good 
> replacement?
> 

You're right, reading further in the document this does not seem to be
a valid replacement. Moreover, it seems that we dont need this option
with armclang - by default it does not generate position-independent
code

> [...]
> 
> > > You would still need --target=.... but that's should depend on
> > > $CROSS_COMPILE
> > > (or any other name we decide).
> > 
> > You're right, I forgot to mention - have not yet built for Arm32 so
> > this is not checked. But, according to manual:
> > 
> > For targets in AArch32 state (--target=arm-arm-none-eabi), there is
> > no
> > default. You must specify either -march (to target an architecture)
> > or
> > -mcpu (to target a processor)
> 
> We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit that
> cortex-a15 
> is probably not the most suitable). If some options should applied to
> the tools 
> as well, then we need to migrated them to config/arm32.mk.

Yes, I do not think we shall specify the particular CPU, better to have
lowest supported architecture defined.

> 
> > [100067_0612_00_en page 1-82]
> > 
> > > > +else
> > > > +CFLAGS += -marm # -march= -mcpu=
> > > >    # Use only if calling $(LD) directly.
> > > >    LDFLAGS_DIRECT += -EL
> > > > +endif
> > > >    
> > > >    IOEMU_CPU_ARCH ?= arm
> > > > diff --git a/config/arm64.mk b/config/arm64.mk
> > > > index aa45772b61..46b203d384 100644
> > > > --- a/config/arm64.mk
> > > > +++ b/config/arm64.mk
> > > > @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> > > >    
> > > >    CONFIG_XEN_INSTALL_SUFFIX :=
> > > >    
> > > > +ifeq ($(armds),y)
> > > > +# VE needed
> > > > +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
> > > > a+nofp+nosimd
> > > 
> > > Same remark for --target.
> > > Also, -march=armv8.1 looks wrong to me because this may generate
> > > code
> > > that will
> > > not work on armv8.0 platform.
> > > 
> > 
> > If I don't specify -march this way, it will built:
> >   1) without some registers, e.g. TTLB0_EL2 support (build fails)
> 
> I guess you mean TTBR0_EL2 here.
> 
> Xen is fully Armv8.0 compliant. So if you can't compile Xen with
> -march=armv8-a 
> then this needs to be investigated and be reported.
> 
> Looking at the error thrown:
> 
> arm64/head.S:399:13: error: expected writable system register or
> pstate
>          msr TTBR0_EL2, x4
> 
> This is likely a compiler bug.
> 

Actually I do not know what is the proper way to report such issues and
get them fixed. My post on ARM forum regarding linker failue has no
comments/reactions, which means it may not be the best way for
reporting. Would it be possible for you to check if we can get some
attention from ARM Compiler folks?

> >   2) with vfp and simd enabled (linking fails)
> > 
> > According to Arm compiler manual:
> > ---
> > For targets in AArch64 state (--target=aarch64-arm-none-eabi),
> > unless
> > you target a particular processor using -mcpu or a particular
> > architecture using -march, the compiler defaults to -march=armv8-a,
> > generating generic code for Armv8‑A in AArch64 state.
> > [100067_0612_00_en page 1-82]
> > ---
> > You can prevent the use of floating-point instructions or floating-
> > point registers for targets in AArch64 state with the
> > -mcpu=name+nofp+nosimd option. Subsequent use of floating-point
> > data
> > types in this mode is unsupported.
> > [100067_0612_00_en page 1-93]
> > ---
> 
> I assume that -mgeneral-regs-only does not work in your case?

Nope :\

> 
> Also, it just occurred to me that nofp+nosimd should only be done for
> the 
> hypervisor. For the tools, we can properly build with SIMD. So this
> will have to 
> be moved in xen/arch/arm/Rules.mk.

Noted.

> 
> Cheers,
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hello Julien, Roger

On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
> (+ Roger)
> 
> On 18/04/2019 12:15, Artem Mygaiev wrote:
> > Hi Julien
> > 
> > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > Hello Julien, Stefano
> > > 
> > > Hi Artem,
> > > 
> > > > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > > > Hi Julien,
> > > > > > > 
> > > > > > > Hi Artem,
> > > > > > > 
> > > > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > This series adds support to build Xen Arm with clang.
> > > > > > > > > This series was
> > > > > > > > > tested
> > > > > > > > > with clang 8.0.
> > > > > > > > > 
> > > > > > > > > Note that I only did build for arm64. I still need to
> > > > > > > > > look at the arm32
> > > > > > > > > build.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I wonder if you have time to try the series with Arm
> > > > > > > > Compiler 6? I am
> > > > > > > > asking because AFAIK it is based on clang/llvm [1] and
> > > > > > > > there's a
> > > > > > > > safety-compliant version of it certified by TUV [2]. I
> > > > > > > > don't have a
> > > > > > > > license yet so cannot try it myself but maybe you have
> > > > > > > > access.
> > > > > > > 
> > > > > > > I gave a quick try to the Arm Compiler. I had to hack a
> > > > > > > bit
> > > > > > > config/StdGNU.mk
> > > > > > > to pass armclang and the appropriate target option.
> > > > > > > 
> > > > > > > I also had a linking issue at the end where __2snprintf
> > > > > > > was
> > > > > > > not found. It
> > > > > > > seems the compiler replace snprintf with __2snprintf, I
> > > > > > > haven't figured out
> > > > > > > why yet.
> > > > > > 
> > > > > > But after these changes, does it work?
> > > > > 
> > > > > I haven't tried to fix the linking issues. I only gave a
> > > > > quick
> > > > > try because Artem
> > > > > asked. I have no plan at the moment to go further than that
> > > > > for
> > > > > now.
> > > > > 
> > > > > Patches are welcomed to add support for armclang.
> > > > > 
> > > > 
> > > > I have implemented a bunch of HACKs [1] so can build Xen master
> > > > with
> > > > armclang 6.12. Not even "smoke"-tested, just trying to identify
> > > > missing
> > > > parameters and proper linker configuration.
> > > 
> > > Thank you for looking at it. Some comments below.
> > > 
> > > > Not yet fixed section placement, lots of warnings from linker
> > > > like:
> > > > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > > > .altinstr_replacement(ns16550.o:42) identifies code, but is in
> > > > a
> > > > section not marked as executable.
> > > 
> > > Instruction in the sections .altinstr_replacement are never meant
> > > to
> > > be executed.
> > > 
> > > I guess this is coming from armlink? Any particular reason to use
> > > armlink and
> > > not ld as we do on clang?
> > > 
> > 
> > Yes, armlink has a "Safety-certified" version of it, while ld
> > doesn't,
> > unfortunately :(
> 
> I am not sure if anyone tried to build Xen other than with ld so far.
> I have 
> CCed Roger who might have a clue whether there are other blocker.
> 

Looking forward to hearing from Roger.

> > Though I must mention that I do not have access to safety-certified
> > version of arm compiler suite, it is not public. Thus checking only
> > against the 30-day trial version of ARM DS 2019-0 which is shipped
> > with
> > compiler 6.12
> 
> Any step towards armclang is good :). We can look at the safety-
> certified 
> version afterwards.
> 
> I don't seem to be able to link with this patch on 6.12:
> 
> Loading object built_in.o.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> Error: L6242E: Cannot link object built_in.o as its attributes are
> incompatible 
> with the image attributes.
>     ... A64 clashes with SoftVFP.
> 
> I am using the following command line to build:
> 
> 42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64
> clang=y 
> armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y
> 

I am still struggling with linker internal fault, not sure what changed
in my environment so it started to fail.

> > > > Also armlink sometimes fails with Internal fault:
> > > > [0xe81a5a:6120001]
> > > 
> > > Do you have more output?
> > 
> > Just opened a ticket in Arm community forums, see details there
> > including full build log (dont want to spam ml)
> > https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001
> > 
> 
> There are nothing interesting in except a flood of "armclang:
> warning: Your 
> license for feature ds_suite_eval will expire in 29 days".
> 
> Let me know how it goes and I can help to resolve it.
> 

This is because of the "free" evaluation license I have, probably can
be safely ignored. So far no reaction on my initial post in Arm
Community.

Playing with linker options I found that the error is caused by the use
of "partial linking model" which is enabled by --partial that
correspond to -r in Xen Makefiles, which is not documented but has
similar effect.

> > > > [1] Diff below just for reference with xen master + Julien's
> > > > clang
> > > > patch series applied
> > > > ---
> > > > 
> > > > diff --git a/Config.mk b/Config.mk
> > > > index 417039d7f6..0fc84293f9 100644
> > > > --- a/Config.mk
> > > > +++ b/Config.mk
> > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> > > >    
> > > >    $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
> > > > statement)
> > > >    $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-
> > > > statement)
> > > > +ifneq ($(armds),y)
> > > >    $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
> > > 
> > > I didn't need this on Arm Compiler 6.11. Can you provide the list
> > > of
> > > error you
> > > get here?
> > 
> > error: unknown warning option '-Wno-unused-but-set-variable'; did
> > you
> > mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-
> > option]
> 
> But cc-option-add should only add the flag if it is supported by the
> compiler. 
> So it is not supported, how come this option is actually used to
> compile?
> 

Because the idea of supported option detection rely on the fact that
compiler will throw an error or warning when makefile try and use the
option being tested, but armclang does not even try to check that and
failing with
  armclang: fatal error: no target architecture given; use --
target=arm-arm-none-eabi or --target=aarch64-arm-none-eabi
and thus cc-option-add does not detect unsupported options

> > > > +endif
> > > >    $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
> > > >    
> > > >    LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > > > @@ -234,9 +236,15 @@ endif
> > > >    APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
> > > >    APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
> > > >    
> > > > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-
> > > > stack-
> > > > protector-all
> > > > +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
> > > > protector-all
> > > >    EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> > > >    
> > > > +ifeq ($(armds),y)
> > > > +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
> > > 
> > > Why do you need this? Is it because armlink does not support
> > > -nopie?
> > 
> > Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide,
> > see
> > [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]
> 
> Hmmm, but the docs says:
> 
> "This option is not supported in AArch64 state". So is that a really
> good 
> replacement?
> 

You're right, reading further in the document this does not seem to be
a valid replacement. Moreover, it seems that we dont need this option
with armclang - by default it does not generate position-independent
code

> [...]
> 
> > > You would still need --target=.... but that's should depend on
> > > $CROSS_COMPILE
> > > (or any other name we decide).
> > 
> > You're right, I forgot to mention - have not yet built for Arm32 so
> > this is not checked. But, according to manual:
> > 
> > For targets in AArch32 state (--target=arm-arm-none-eabi), there is
> > no
> > default. You must specify either -march (to target an architecture)
> > or
> > -mcpu (to target a processor)
> 
> We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit that
> cortex-a15 
> is probably not the most suitable). If some options should applied to
> the tools 
> as well, then we need to migrated them to config/arm32.mk.

Yes, I do not think we shall specify the particular CPU, better to have
lowest supported architecture defined.

> 
> > [100067_0612_00_en page 1-82]
> > 
> > > > +else
> > > > +CFLAGS += -marm # -march= -mcpu=
> > > >    # Use only if calling $(LD) directly.
> > > >    LDFLAGS_DIRECT += -EL
> > > > +endif
> > > >    
> > > >    IOEMU_CPU_ARCH ?= arm
> > > > diff --git a/config/arm64.mk b/config/arm64.mk
> > > > index aa45772b61..46b203d384 100644
> > > > --- a/config/arm64.mk
> > > > +++ b/config/arm64.mk
> > > > @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> > > >    
> > > >    CONFIG_XEN_INSTALL_SUFFIX :=
> > > >    
> > > > +ifeq ($(armds),y)
> > > > +# VE needed
> > > > +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
> > > > a+nofp+nosimd
> > > 
> > > Same remark for --target.
> > > Also, -march=armv8.1 looks wrong to me because this may generate
> > > code
> > > that will
> > > not work on armv8.0 platform.
> > > 
> > 
> > If I don't specify -march this way, it will built:
> >   1) without some registers, e.g. TTLB0_EL2 support (build fails)
> 
> I guess you mean TTBR0_EL2 here.
> 
> Xen is fully Armv8.0 compliant. So if you can't compile Xen with
> -march=armv8-a 
> then this needs to be investigated and be reported.
> 
> Looking at the error thrown:
> 
> arm64/head.S:399:13: error: expected writable system register or
> pstate
>          msr TTBR0_EL2, x4
> 
> This is likely a compiler bug.
> 

Actually I do not know what is the proper way to report such issues and
get them fixed. My post on ARM forum regarding linker failue has no
comments/reactions, which means it may not be the best way for
reporting. Would it be possible for you to check if we can get some
attention from ARM Compiler folks?

> >   2) with vfp and simd enabled (linking fails)
> > 
> > According to Arm compiler manual:
> > ---
> > For targets in AArch64 state (--target=aarch64-arm-none-eabi),
> > unless
> > you target a particular processor using -mcpu or a particular
> > architecture using -march, the compiler defaults to -march=armv8-a,
> > generating generic code for Armv8‑A in AArch64 state.
> > [100067_0612_00_en page 1-82]
> > ---
> > You can prevent the use of floating-point instructions or floating-
> > point registers for targets in AArch64 state with the
> > -mcpu=name+nofp+nosimd option. Subsequent use of floating-point
> > data
> > types in this mode is unsupported.
> > [100067_0612_00_en page 1-93]
> > ---
> 
> I assume that -mgeneral-regs-only does not work in your case?

Nope :\

> 
> Also, it just occurred to me that nofp+nosimd should only be done for
> the 
> hypervisor. For the tools, we can properly build with SIMD. So this
> will have to 
> be moved in xen/arch/arm/Rules.mk.

Noted.

> 
> Cheers,
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Roger Pau Monné]

On Thu, Apr 18, 2019 at 07:33:05PM +0100, Julien Grall wrote:
> (+ Roger)
> 
> On 18/04/2019 12:15, Artem Mygaiev wrote:
> > Hi Julien
> > 
> > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > Hello Julien, Stefano
> > > 
> > > Hi Artem,
> > > 
> > > > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > > > Hi Julien,
> > > > > > > 
> > > > > > > Hi Artem,
> > > > > > > 
> > > > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > This series adds support to build Xen Arm with clang.
> > > > > > > > > This series was
> > > > > > > > > tested
> > > > > > > > > with clang 8.0.
> > > > > > > > > 
> > > > > > > > > Note that I only did build for arm64. I still need to
> > > > > > > > > look at the arm32
> > > > > > > > > build.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I wonder if you have time to try the series with Arm
> > > > > > > > Compiler 6? I am
> > > > > > > > asking because AFAIK it is based on clang/llvm [1] and
> > > > > > > > there's a
> > > > > > > > safety-compliant version of it certified by TUV [2]. I
> > > > > > > > don't have a
> > > > > > > > license yet so cannot try it myself but maybe you have
> > > > > > > > access.
> > > > > > > 
> > > > > > > I gave a quick try to the Arm Compiler. I had to hack a bit
> > > > > > > config/StdGNU.mk
> > > > > > > to pass armclang and the appropriate target option.
> > > > > > > 
> > > > > > > I also had a linking issue at the end where __2snprintf was
> > > > > > > not found. It
> > > > > > > seems the compiler replace snprintf with __2snprintf, I
> > > > > > > haven't figured out
> > > > > > > why yet.
> > > > > > 
> > > > > > But after these changes, does it work?
> > > > > 
> > > > > I haven't tried to fix the linking issues. I only gave a quick
> > > > > try because Artem
> > > > > asked. I have no plan at the moment to go further than that for
> > > > > now.
> > > > > 
> > > > > Patches are welcomed to add support for armclang.
> > > > > 
> > > > 
> > > > I have implemented a bunch of HACKs [1] so can build Xen master
> > > > with
> > > > armclang 6.12. Not even "smoke"-tested, just trying to identify
> > > > missing
> > > > parameters and proper linker configuration.
> > > 
> > > Thank you for looking at it. Some comments below.
> > > 
> > > > Not yet fixed section placement, lots of warnings from linker like:
> > > > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > > > .altinstr_replacement(ns16550.o:42) identifies code, but is in a
> > > > section not marked as executable.
> > > 
> > > Instruction in the sections .altinstr_replacement are never meant to
> > > be executed.
> > > 
> > > I guess this is coming from armlink? Any particular reason to use
> > > armlink and
> > > not ld as we do on clang?
> > > 
> > 
> > Yes, armlink has a "Safety-certified" version of it, while ld doesn't,
> > unfortunately :(
> 
> I am not sure if anyone tried to build Xen other than with ld so far. I have
> CCed Roger who might have a clue whether there are other blocker.

On x86 you can build Xen and the toolstack with a full llvm based
toolchain (clang + lld). In fact that's how the Xen packages for
FreeBSD are built, IIRC lld and clang 6 and greater should work fine
with Xen 4.12 and upwards.

I had to do some fixes to lld and clang in order to understand some of
the assembly tricks that Xen does, but it was quite minor.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Roger Pau Monné]

On Thu, Apr 18, 2019 at 07:33:05PM +0100, Julien Grall wrote:
> (+ Roger)
> 
> On 18/04/2019 12:15, Artem Mygaiev wrote:
> > Hi Julien
> > 
> > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > Hello Julien, Stefano
> > > 
> > > Hi Artem,
> > > 
> > > > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > > > Hi Julien,
> > > > > > > 
> > > > > > > Hi Artem,
> > > > > > > 
> > > > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > This series adds support to build Xen Arm with clang.
> > > > > > > > > This series was
> > > > > > > > > tested
> > > > > > > > > with clang 8.0.
> > > > > > > > > 
> > > > > > > > > Note that I only did build for arm64. I still need to
> > > > > > > > > look at the arm32
> > > > > > > > > build.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > I wonder if you have time to try the series with Arm
> > > > > > > > Compiler 6? I am
> > > > > > > > asking because AFAIK it is based on clang/llvm [1] and
> > > > > > > > there's a
> > > > > > > > safety-compliant version of it certified by TUV [2]. I
> > > > > > > > don't have a
> > > > > > > > license yet so cannot try it myself but maybe you have
> > > > > > > > access.
> > > > > > > 
> > > > > > > I gave a quick try to the Arm Compiler. I had to hack a bit
> > > > > > > config/StdGNU.mk
> > > > > > > to pass armclang and the appropriate target option.
> > > > > > > 
> > > > > > > I also had a linking issue at the end where __2snprintf was
> > > > > > > not found. It
> > > > > > > seems the compiler replace snprintf with __2snprintf, I
> > > > > > > haven't figured out
> > > > > > > why yet.
> > > > > > 
> > > > > > But after these changes, does it work?
> > > > > 
> > > > > I haven't tried to fix the linking issues. I only gave a quick
> > > > > try because Artem
> > > > > asked. I have no plan at the moment to go further than that for
> > > > > now.
> > > > > 
> > > > > Patches are welcomed to add support for armclang.
> > > > > 
> > > > 
> > > > I have implemented a bunch of HACKs [1] so can build Xen master
> > > > with
> > > > armclang 6.12. Not even "smoke"-tested, just trying to identify
> > > > missing
> > > > parameters and proper linker configuration.
> > > 
> > > Thank you for looking at it. Some comments below.
> > > 
> > > > Not yet fixed section placement, lots of warnings from linker like:
> > > > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > > > .altinstr_replacement(ns16550.o:42) identifies code, but is in a
> > > > section not marked as executable.
> > > 
> > > Instruction in the sections .altinstr_replacement are never meant to
> > > be executed.
> > > 
> > > I guess this is coming from armlink? Any particular reason to use
> > > armlink and
> > > not ld as we do on clang?
> > > 
> > 
> > Yes, armlink has a "Safety-certified" version of it, while ld doesn't,
> > unfortunately :(
> 
> I am not sure if anyone tried to build Xen other than with ld so far. I have
> CCed Roger who might have a clue whether there are other blocker.

On x86 you can build Xen and the toolstack with a full llvm based
toolchain (clang + lld). In fact that's how the Xen packages for
FreeBSD are built, IIRC lld and clang 6 and greater should work fine
with Xen 4.12 and upwards.

I had to do some fixes to lld and clang in order to understand some of
the assembly tricks that Xen does, but it was quite minor.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 01/12] xen: clang: Support correctly cross-compile

[Julien Grall]

Hi,

On 4/19/19 7:47 PM, Stefano Stabellini wrote:
> On Fri, 29 Mar 2019, Jan Beulich wrote:
>>>>> On 29.03.19 at 10:41, <julien.grall@arm.com> wrote:
>>> On 28/03/2019 09:55, Jan Beulich wrote:
>>>>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>>>>> Clang uses "-target" option for cross-compilation.
>>>>
>>>>> --- a/config/StdGNU.mk
>>>>> +++ b/config/StdGNU.mk
>>>>> @@ -1,8 +1,13 @@
>>>>>    AS         = $(CROSS_COMPILE)as
>>>>>    LD         = $(CROSS_COMPILE)ld
>>>>>    ifeq ($(clang),y)
>>>>> -CC         = $(CROSS_COMPILE)clang
>>>>> -CXX        = $(CROSS_COMPILE)clang++
>>>>> +ifneq ($(CROSS_COMPILE),)
>>>>> +CC         = clang -target $(CROSS_COMPILE:-=)
>>>>> +CXX        = clang++ -target $(CROSS_COMPILE:-=)
>>>>
>>>> Is dropping dashes from the variable uniformly correct? If so,
>>>> could you please clarify in the commit message why that is?
>>> The target option requires the following format:
>>>
>>> <arch><sub>-<vendor>-<sys>-<abi>
>>>
>>> In other places, we need the trailing dash as GNU tools are using the same
>>> format as above with a dash to separate the tool name.
>>
>> Oh, I'm sorry - I keep forgetting that the substitution form you
>> use only fiddles with trailing dashes. Of course I won't insist, but
>> I'd prefer the more obvious $(patsubst %-,%,$(CROSS_COMPILE))
>> to be used instead, despite realizing that it's meaningfully longer.
> 
> Either way to do variable manipulation is OK, but it would be good to
> add Julien's explanation of the -target expected format in the commit
> message. I don't have any other comments on this patch.

Not even regarding <b4405caf-6b06-6066-8f48-f35ba67bbdd2@arm.com>?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 01/12] xen: clang: Support correctly cross-compile

[Julien Grall]

Hi,

On 4/19/19 7:47 PM, Stefano Stabellini wrote:
> On Fri, 29 Mar 2019, Jan Beulich wrote:
>>>>> On 29.03.19 at 10:41, <julien.grall@arm.com> wrote:
>>> On 28/03/2019 09:55, Jan Beulich wrote:
>>>>>>> On 27.03.19 at 19:45, <julien.grall@arm.com> wrote:
>>>>> Clang uses "-target" option for cross-compilation.
>>>>
>>>>> --- a/config/StdGNU.mk
>>>>> +++ b/config/StdGNU.mk
>>>>> @@ -1,8 +1,13 @@
>>>>>    AS         = $(CROSS_COMPILE)as
>>>>>    LD         = $(CROSS_COMPILE)ld
>>>>>    ifeq ($(clang),y)
>>>>> -CC         = $(CROSS_COMPILE)clang
>>>>> -CXX        = $(CROSS_COMPILE)clang++
>>>>> +ifneq ($(CROSS_COMPILE),)
>>>>> +CC         = clang -target $(CROSS_COMPILE:-=)
>>>>> +CXX        = clang++ -target $(CROSS_COMPILE:-=)
>>>>
>>>> Is dropping dashes from the variable uniformly correct? If so,
>>>> could you please clarify in the commit message why that is?
>>> The target option requires the following format:
>>>
>>> <arch><sub>-<vendor>-<sys>-<abi>
>>>
>>> In other places, we need the trailing dash as GNU tools are using the same
>>> format as above with a dash to separate the tool name.
>>
>> Oh, I'm sorry - I keep forgetting that the substitution form you
>> use only fiddles with trailing dashes. Of course I won't insist, but
>> I'd prefer the more obvious $(patsubst %-,%,$(CROSS_COMPILE))
>> to be used instead, despite realizing that it's meaningfully longer.
> 
> Either way to do variable manipulation is OK, but it would be good to
> add Julien's explanation of the -target expected format in the commit
> message. I don't have any other comments on this patch.

Not even regarding <b4405caf-6b06-6066-8f48-f35ba67bbdd2@arm.com>?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi Artem,

On 4/23/19 2:39 PM, Artem Mygaiev wrote:
> Hello Julien, Roger
> 
> On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
>> (+ Roger)
>>
>> On 18/04/2019 12:15, Artem Mygaiev wrote:
>>> Hi Julien
>>>
>>> On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
>>>> On 18/04/2019 10:15, Artem Mygaiev wrote:
>>>>> Hello Julien, Stefano
>>>>
>>>> Hi Artem,
>>>>
>>>>> On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16/04/2019 23:43, Stefano Stabellini wrote:
>>>>>>> On Fri, 29 Mar 2019, Julien Grall wrote:
>>>>>>>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>>>>>>>> Hi Julien,
>>>>>>>>
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> This series adds support to build Xen Arm with clang.
>>>>>>>>>> This series was
>>>>>>>>>> tested
>>>>>>>>>> with clang 8.0.
>>>>>>>>>>
>>>>>>>>>> Note that I only did build for arm64. I still need to
>>>>>>>>>> look at the arm32
>>>>>>>>>> build.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I wonder if you have time to try the series with Arm
>>>>>>>>> Compiler 6? I am
>>>>>>>>> asking because AFAIK it is based on clang/llvm [1] and
>>>>>>>>> there's a
>>>>>>>>> safety-compliant version of it certified by TUV [2]. I
>>>>>>>>> don't have a
>>>>>>>>> license yet so cannot try it myself but maybe you have
>>>>>>>>> access.
>>>>>>>>
>>>>>>>> I gave a quick try to the Arm Compiler. I had to hack a
>>>>>>>> bit
>>>>>>>> config/StdGNU.mk
>>>>>>>> to pass armclang and the appropriate target option.
>>>>>>>>
>>>>>>>> I also had a linking issue at the end where __2snprintf
>>>>>>>> was
>>>>>>>> not found. It
>>>>>>>> seems the compiler replace snprintf with __2snprintf, I
>>>>>>>> haven't figured out
>>>>>>>> why yet.
>>>>>>>
>>>>>>> But after these changes, does it work?
>>>>>>
>>>>>> I haven't tried to fix the linking issues. I only gave a
>>>>>> quick
>>>>>> try because Artem
>>>>>> asked. I have no plan at the moment to go further than that
>>>>>> for
>>>>>> now.
>>>>>>
>>>>>> Patches are welcomed to add support for armclang.
>>>>>>
>>>>>
>>>>> I have implemented a bunch of HACKs [1] so can build Xen master
>>>>> with
>>>>> armclang 6.12. Not even "smoke"-tested, just trying to identify
>>>>> missing
>>>>> parameters and proper linker configuration.
>>>>
>>>> Thank you for looking at it. Some comments below.
>>>>
>>>>> Not yet fixed section placement, lots of warnings from linker
>>>>> like:
>>>>> Warning: L6170W: Mapping symbol #40 '$x.20' in
>>>>> .altinstr_replacement(ns16550.o:42) identifies code, but is in
>>>>> a
>>>>> section not marked as executable.
>>>>
>>>> Instruction in the sections .altinstr_replacement are never meant
>>>> to
>>>> be executed.
>>>>
>>>> I guess this is coming from armlink? Any particular reason to use
>>>> armlink and
>>>> not ld as we do on clang?
>>>>
>>>
>>> Yes, armlink has a "Safety-certified" version of it, while ld
>>> doesn't,
>>> unfortunately :(
>>
>> I am not sure if anyone tried to build Xen other than with ld so far.
>> I have
>> CCed Roger who might have a clue whether there are other blocker.
>>
> 
> Looking forward to hearing from Roger.
> 
>>> Though I must mention that I do not have access to safety-certified
>>> version of arm compiler suite, it is not public. Thus checking only
>>> against the 30-day trial version of ARM DS 2019-0 which is shipped
>>> with
>>> compiler 6.12
>>
>> Any step towards armclang is good :). We can look at the safety-
>> certified
>> version afterwards.
>>
>> I don't seem to be able to link with this patch on 6.12:
>>
>> Loading object built_in.o.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>>
>> I am using the following command line to build:
>>
>> 42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64
>> clang=y
>> armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y
>>
> 
> I am still struggling with linker internal fault, not sure what changed
> in my environment so it started to fail.
> 
>>>>> Also armlink sometimes fails with Internal fault:
>>>>> [0xe81a5a:6120001]
>>>>
>>>> Do you have more output?
>>>
>>> Just opened a ticket in Arm community forums, see details there
>>> including full build log (dont want to spam ml)
>>> https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001
>>>
>>
>> There are nothing interesting in except a flood of "armclang:
>> warning: Your
>> license for feature ds_suite_eval will expire in 29 days".
>>
>> Let me know how it goes and I can help to resolve it.
>>
> 
> This is because of the "free" evaluation license I have, probably can
> be safely ignored.

I know :). I was pointed out how verbose it was compare to the lack of 
information regarding the internal fault.

> So far no reaction on my initial post in Arm Community.
> 
> Playing with linker options I found that the error is caused by the use
> of "partial linking model" which is enabled by --partial that
> correspond to -r in Xen Makefiles, which is not documented but has
> similar effect.

Do you mean the "Internal Fault"?

> 
>>>>> [1] Diff below just for reference with xen master + Julien's
>>>>> clang
>>>>> patch series applied
>>>>> ---
>>>>>
>>>>> diff --git a/Config.mk b/Config.mk
>>>>> index 417039d7f6..0fc84293f9 100644
>>>>> --- a/Config.mk
>>>>> +++ b/Config.mk
>>>>> @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
>>>>>     
>>>>>     $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
>>>>> statement)
>>>>>     $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-
>>>>> statement)
>>>>> +ifneq ($(armds),y)
>>>>>     $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
>>>>
>>>> I didn't need this on Arm Compiler 6.11. Can you provide the list
>>>> of
>>>> error you
>>>> get here?
>>>
>>> error: unknown warning option '-Wno-unused-but-set-variable'; did
>>> you
>>> mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-
>>> option]
>>
>> But cc-option-add should only add the flag if it is supported by the
>> compiler.
>> So it is not supported, how come this option is actually used to
>> compile?
>>
> 
> Because the idea of supported option detection rely on the fact that
> compiler will throw an error or warning when makefile try and use the
> option being tested, but armclang does not even try to check that and
> failing with
>    armclang: fatal error: no target architecture given; use --
> target=arm-arm-none-eabi or --target=aarch64-arm-none-eabi
> and thus cc-option-add does not detect unsupported options

I think defining CC as below should do the trick:

CC := armclang --target=aarch64-arm-none-eabi

> 
>>>>> +endif
>>>>>     $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
>>>>>     
>>>>>     LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
>>>>> @@ -234,9 +236,15 @@ endif
>>>>>     APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
>>>>>     APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>>>>>     
>>>>> -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-
>>>>> stack-
>>>>> protector-all
>>>>> +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
>>>>> protector-all
>>>>>     EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
>>>>>     
>>>>> +ifeq ($(armds),y)
>>>>> +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
>>>>
>>>> Why do you need this? Is it because armlink does not support
>>>> -nopie?
>>>
>>> Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide,
>>> see
>>> [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]
>>
>> Hmmm, but the docs says:
>>
>> "This option is not supported in AArch64 state". So is that a really
>> good
>> replacement?
>>
> 
> You're right, reading further in the document this does not seem to be
> a valid replacement. Moreover, it seems that we dont need this option
> with armclang - by default it does not generate position-independent
> code

As this always been the case? I know that for GCC it depends on the on 
distro/version of the compiler.

>> [...]
>>
>>>> You would still need --target=.... but that's should depend on
>>>> $CROSS_COMPILE
>>>> (or any other name we decide).
>>>
>>> You're right, I forgot to mention - have not yet built for Arm32 so
>>> this is not checked. But, according to manual:
>>>
>>> For targets in AArch32 state (--target=arm-arm-none-eabi), there is
>>> no
>>> default. You must specify either -march (to target an architecture)
>>> or
>>> -mcpu (to target a processor)
>>
>> We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit that
>> cortex-a15
>> is probably not the most suitable). If some options should applied to
>> the tools
>> as well, then we need to migrated them to config/arm32.mk.
> 
> Yes, I do not think we shall specify the particular CPU, better to have
> lowest supported architecture defined.

I vaguely remembered to try to replace cortex-a15 with something else in 
the past. IIRC, the problem was armv7-a does not necessarily include 
virt extension.

Trying again today with -march=armv7-a instead of -mcpu=cortex-a15, I 
can see build error when using Linaro GCC 6.1-2016.80:

{standard input}: Assembler messages:
{standard input}:285: Error: selected processor does not support `smc 
#0' in ARM mode
{standard input}:429: Error: selected processor does not support `smc 
#0' in ARM mode
{standard input}:462: Error: selected processor does not support `smc 
#0' in ARM mode
{standard input}:539: Error: selected processor does not support `smc 
#0' in ARM mode
/home/julieng/works/xen/xen/Rules.mk:196: recipe for target 
'cpuerrata.o' failed
make[3]: *** [cpuerrata.o] Error 1

I think this one is solvable by specifying the secure extension. But it 
might be possible there are other issues with older compiler (i.e 4.6 & co).

>>
>>> [100067_0612_00_en page 1-82]
>>>
>>>>> +else
>>>>> +CFLAGS += -marm # -march= -mcpu=
>>>>>     # Use only if calling $(LD) directly.
>>>>>     LDFLAGS_DIRECT += -EL
>>>>> +endif
>>>>>     
>>>>>     IOEMU_CPU_ARCH ?= arm
>>>>> diff --git a/config/arm64.mk b/config/arm64.mk
>>>>> index aa45772b61..46b203d384 100644
>>>>> --- a/config/arm64.mk
>>>>> +++ b/config/arm64.mk
>>>>> @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>>>>>     
>>>>>     CONFIG_XEN_INSTALL_SUFFIX :=
>>>>>     
>>>>> +ifeq ($(armds),y)
>>>>> +# VE needed
>>>>> +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
>>>>> a+nofp+nosimd
>>>>
>>>> Same remark for --target.
>>>> Also, -march=armv8.1 looks wrong to me because this may generate
>>>> code
>>>> that will
>>>> not work on armv8.0 platform.
>>>>
>>>
>>> If I don't specify -march this way, it will built:
>>>    1) without some registers, e.g. TTLB0_EL2 support (build fails)
>>
>> I guess you mean TTBR0_EL2 here.
>>
>> Xen is fully Armv8.0 compliant. So if you can't compile Xen with
>> -march=armv8-a
>> then this needs to be investigated and be reported.
>>
>> Looking at the error thrown:
>>
>> arm64/head.S:399:13: error: expected writable system register or
>> pstate
>>           msr TTBR0_EL2, x4
>>
>> This is likely a compiler bug.
>>
> 
> Actually I do not know what is the proper way to report such issues and
> get them fixed. My post on ARM forum regarding linker failue has no
> comments/reactions, which means it may not be the best way for
> reporting. Would it be possible for you to check if we can get some
> attention from ARM Compiler folks?

I will have a chat and let you know.

> 
>>>    2) with vfp and simd enabled (linking fails)
>>>
>>> According to Arm compiler manual:
>>> ---
>>> For targets in AArch64 state (--target=aarch64-arm-none-eabi),
>>> unless
>>> you target a particular processor using -mcpu or a particular
>>> architecture using -march, the compiler defaults to -march=armv8-a,
>>> generating generic code for Armv8‑A in AArch64 state.
>>> [100067_0612_00_en page 1-82]
>>> ---
>>> You can prevent the use of floating-point instructions or floating-
>>> point registers for targets in AArch64 state with the
>>> -mcpu=name+nofp+nosimd option. Subsequent use of floating-point
>>> data
>>> types in this mode is unsupported.
>>> [100067_0612_00_en page 1-93]
>>> ---
>>
>> I assume that -mgeneral-regs-only does not work in your case?
> 
> Nope :\

It would be interesting to know whether -march=armv8-a... works on all 
GCC version we support.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Julien Grall]

Hi Artem,

On 4/23/19 2:39 PM, Artem Mygaiev wrote:
> Hello Julien, Roger
> 
> On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
>> (+ Roger)
>>
>> On 18/04/2019 12:15, Artem Mygaiev wrote:
>>> Hi Julien
>>>
>>> On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
>>>> On 18/04/2019 10:15, Artem Mygaiev wrote:
>>>>> Hello Julien, Stefano
>>>>
>>>> Hi Artem,
>>>>
>>>>> On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 16/04/2019 23:43, Stefano Stabellini wrote:
>>>>>>> On Fri, 29 Mar 2019, Julien Grall wrote:
>>>>>>>> On 28/03/2019 11:27, Artem Mygaiev wrote:
>>>>>>>>> Hi Julien,
>>>>>>>>
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>>> On Wed, 2019-03-27 at 18:45 +0000, Julien Grall wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> This series adds support to build Xen Arm with clang.
>>>>>>>>>> This series was
>>>>>>>>>> tested
>>>>>>>>>> with clang 8.0.
>>>>>>>>>>
>>>>>>>>>> Note that I only did build for arm64. I still need to
>>>>>>>>>> look at the arm32
>>>>>>>>>> build.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I wonder if you have time to try the series with Arm
>>>>>>>>> Compiler 6? I am
>>>>>>>>> asking because AFAIK it is based on clang/llvm [1] and
>>>>>>>>> there's a
>>>>>>>>> safety-compliant version of it certified by TUV [2]. I
>>>>>>>>> don't have a
>>>>>>>>> license yet so cannot try it myself but maybe you have
>>>>>>>>> access.
>>>>>>>>
>>>>>>>> I gave a quick try to the Arm Compiler. I had to hack a
>>>>>>>> bit
>>>>>>>> config/StdGNU.mk
>>>>>>>> to pass armclang and the appropriate target option.
>>>>>>>>
>>>>>>>> I also had a linking issue at the end where __2snprintf
>>>>>>>> was
>>>>>>>> not found. It
>>>>>>>> seems the compiler replace snprintf with __2snprintf, I
>>>>>>>> haven't figured out
>>>>>>>> why yet.
>>>>>>>
>>>>>>> But after these changes, does it work?
>>>>>>
>>>>>> I haven't tried to fix the linking issues. I only gave a
>>>>>> quick
>>>>>> try because Artem
>>>>>> asked. I have no plan at the moment to go further than that
>>>>>> for
>>>>>> now.
>>>>>>
>>>>>> Patches are welcomed to add support for armclang.
>>>>>>
>>>>>
>>>>> I have implemented a bunch of HACKs [1] so can build Xen master
>>>>> with
>>>>> armclang 6.12. Not even "smoke"-tested, just trying to identify
>>>>> missing
>>>>> parameters and proper linker configuration.
>>>>
>>>> Thank you for looking at it. Some comments below.
>>>>
>>>>> Not yet fixed section placement, lots of warnings from linker
>>>>> like:
>>>>> Warning: L6170W: Mapping symbol #40 '$x.20' in
>>>>> .altinstr_replacement(ns16550.o:42) identifies code, but is in
>>>>> a
>>>>> section not marked as executable.
>>>>
>>>> Instruction in the sections .altinstr_replacement are never meant
>>>> to
>>>> be executed.
>>>>
>>>> I guess this is coming from armlink? Any particular reason to use
>>>> armlink and
>>>> not ld as we do on clang?
>>>>
>>>
>>> Yes, armlink has a "Safety-certified" version of it, while ld
>>> doesn't,
>>> unfortunately :(
>>
>> I am not sure if anyone tried to build Xen other than with ld so far.
>> I have
>> CCed Roger who might have a clue whether there are other blocker.
>>
> 
> Looking forward to hearing from Roger.
> 
>>> Though I must mention that I do not have access to safety-certified
>>> version of arm compiler suite, it is not public. Thus checking only
>>> against the 30-day trial version of ARM DS 2019-0 which is shipped
>>> with
>>> compiler 6.12
>>
>> Any step towards armclang is good :). We can look at the safety-
>> certified
>> version afterwards.
>>
>> I don't seem to be able to link with this patch on 6.12:
>>
>> Loading object built_in.o.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>> Error: L6242E: Cannot link object built_in.o as its attributes are
>> incompatible
>> with the image attributes.
>>      ... A64 clashes with SoftVFP.
>>
>> I am using the following command line to build:
>>
>> 42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64
>> clang=y
>> armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y
>>
> 
> I am still struggling with linker internal fault, not sure what changed
> in my environment so it started to fail.
> 
>>>>> Also armlink sometimes fails with Internal fault:
>>>>> [0xe81a5a:6120001]
>>>>
>>>> Do you have more output?
>>>
>>> Just opened a ticket in Arm community forums, see details there
>>> including full build log (dont want to spam ml)
>>> https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001
>>>
>>
>> There are nothing interesting in except a flood of "armclang:
>> warning: Your
>> license for feature ds_suite_eval will expire in 29 days".
>>
>> Let me know how it goes and I can help to resolve it.
>>
> 
> This is because of the "free" evaluation license I have, probably can
> be safely ignored.

I know :). I was pointed out how verbose it was compare to the lack of 
information regarding the internal fault.

> So far no reaction on my initial post in Arm Community.
> 
> Playing with linker options I found that the error is caused by the use
> of "partial linking model" which is enabled by --partial that
> correspond to -r in Xen Makefiles, which is not documented but has
> similar effect.

Do you mean the "Internal Fault"?

> 
>>>>> [1] Diff below just for reference with xen master + Julien's
>>>>> clang
>>>>> patch series applied
>>>>> ---
>>>>>
>>>>> diff --git a/Config.mk b/Config.mk
>>>>> index 417039d7f6..0fc84293f9 100644
>>>>> --- a/Config.mk
>>>>> +++ b/Config.mk
>>>>> @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
>>>>>     
>>>>>     $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-after-
>>>>> statement)
>>>>>     $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-
>>>>> statement)
>>>>> +ifneq ($(armds),y)
>>>>>     $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-variable)
>>>>
>>>> I didn't need this on Arm Compiler 6.11. Can you provide the list
>>>> of
>>>> error you
>>>> get here?
>>>
>>> error: unknown warning option '-Wno-unused-but-set-variable'; did
>>> you
>>> mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-
>>> option]
>>
>> But cc-option-add should only add the flag if it is supported by the
>> compiler.
>> So it is not supported, how come this option is actually used to
>> compile?
>>
> 
> Because the idea of supported option detection rely on the fact that
> compiler will throw an error or warning when makefile try and use the
> option being tested, but armclang does not even try to check that and
> failing with
>    armclang: fatal error: no target architecture given; use --
> target=arm-arm-none-eabi or --target=aarch64-arm-none-eabi
> and thus cc-option-add does not detect unsupported options

I think defining CC as below should do the trick:

CC := armclang --target=aarch64-arm-none-eabi

> 
>>>>> +endif
>>>>>     $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-typedefs)
>>>>>     
>>>>>     LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
>>>>> @@ -234,9 +236,15 @@ endif
>>>>>     APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
>>>>>     APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
>>>>>     
>>>>> -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-
>>>>> stack-
>>>>> protector-all
>>>>> +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
>>>>> protector-all
>>>>>     EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
>>>>>     
>>>>> +ifeq ($(armds),y)
>>>>> +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
>>>>
>>>> Why do you need this? Is it because armlink does not support
>>>> -nopie?
>>>
>>> Yes. ropi/rwpi are according to Arm Compiler 6.12 reference guide,
>>> see
>>> [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]
>>
>> Hmmm, but the docs says:
>>
>> "This option is not supported in AArch64 state". So is that a really
>> good
>> replacement?
>>
> 
> You're right, reading further in the document this does not seem to be
> a valid replacement. Moreover, it seems that we dont need this option
> with armclang - by default it does not generate position-independent
> code

As this always been the case? I know that for GCC it depends on the on 
distro/version of the compiler.

>> [...]
>>
>>>> You would still need --target=.... but that's should depend on
>>>> $CROSS_COMPILE
>>>> (or any other name we decide).
>>>
>>> You're right, I forgot to mention - have not yet built for Arm32 so
>>> this is not checked. But, according to manual:
>>>
>>> For targets in AArch32 state (--target=arm-arm-none-eabi), there is
>>> no
>>> default. You must specify either -march (to target an architecture)
>>> or
>>> -mcpu (to target a processor)
>>
>> We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit that
>> cortex-a15
>> is probably not the most suitable). If some options should applied to
>> the tools
>> as well, then we need to migrated them to config/arm32.mk.
> 
> Yes, I do not think we shall specify the particular CPU, better to have
> lowest supported architecture defined.

I vaguely remembered to try to replace cortex-a15 with something else in 
the past. IIRC, the problem was armv7-a does not necessarily include 
virt extension.

Trying again today with -march=armv7-a instead of -mcpu=cortex-a15, I 
can see build error when using Linaro GCC 6.1-2016.80:

{standard input}: Assembler messages:
{standard input}:285: Error: selected processor does not support `smc 
#0' in ARM mode
{standard input}:429: Error: selected processor does not support `smc 
#0' in ARM mode
{standard input}:462: Error: selected processor does not support `smc 
#0' in ARM mode
{standard input}:539: Error: selected processor does not support `smc 
#0' in ARM mode
/home/julieng/works/xen/xen/Rules.mk:196: recipe for target 
'cpuerrata.o' failed
make[3]: *** [cpuerrata.o] Error 1

I think this one is solvable by specifying the secure extension. But it 
might be possible there are other issues with older compiler (i.e 4.6 & co).

>>
>>> [100067_0612_00_en page 1-82]
>>>
>>>>> +else
>>>>> +CFLAGS += -marm # -march= -mcpu=
>>>>>     # Use only if calling $(LD) directly.
>>>>>     LDFLAGS_DIRECT += -EL
>>>>> +endif
>>>>>     
>>>>>     IOEMU_CPU_ARCH ?= arm
>>>>> diff --git a/config/arm64.mk b/config/arm64.mk
>>>>> index aa45772b61..46b203d384 100644
>>>>> --- a/config/arm64.mk
>>>>> +++ b/config/arm64.mk
>>>>> @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
>>>>>     
>>>>>     CONFIG_XEN_INSTALL_SUFFIX :=
>>>>>     
>>>>> +ifeq ($(armds),y)
>>>>> +# VE needed
>>>>> +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
>>>>> a+nofp+nosimd
>>>>
>>>> Same remark for --target.
>>>> Also, -march=armv8.1 looks wrong to me because this may generate
>>>> code
>>>> that will
>>>> not work on armv8.0 platform.
>>>>
>>>
>>> If I don't specify -march this way, it will built:
>>>    1) without some registers, e.g. TTLB0_EL2 support (build fails)
>>
>> I guess you mean TTBR0_EL2 here.
>>
>> Xen is fully Armv8.0 compliant. So if you can't compile Xen with
>> -march=armv8-a
>> then this needs to be investigated and be reported.
>>
>> Looking at the error thrown:
>>
>> arm64/head.S:399:13: error: expected writable system register or
>> pstate
>>           msr TTBR0_EL2, x4
>>
>> This is likely a compiler bug.
>>
> 
> Actually I do not know what is the proper way to report such issues and
> get them fixed. My post on ARM forum regarding linker failue has no
> comments/reactions, which means it may not be the best way for
> reporting. Would it be possible for you to check if we can get some
> attention from ARM Compiler folks?

I will have a chat and let you know.

> 
>>>    2) with vfp and simd enabled (linking fails)
>>>
>>> According to Arm compiler manual:
>>> ---
>>> For targets in AArch64 state (--target=aarch64-arm-none-eabi),
>>> unless
>>> you target a particular processor using -mcpu or a particular
>>> architecture using -march, the compiler defaults to -march=armv8-a,
>>> generating generic code for Armv8‑A in AArch64 state.
>>> [100067_0612_00_en page 1-82]
>>> ---
>>> You can prevent the use of floating-point instructions or floating-
>>> point registers for targets in AArch64 state with the
>>> -mcpu=name+nofp+nosimd option. Subsequent use of floating-point
>>> data
>>> types in this mode is unsupported.
>>> [100067_0612_00_en page 1-93]
>>> ---
>>
>> I assume that -mgeneral-regs-only does not work in your case?
> 
> Nope :\

It would be interesting to know whether -march=armv8-a... works on all 
GCC version we support.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hello Julien

On Wed, 2019-04-24 at 22:07 +0100, Julien Grall wrote:
> Hi Artem,
> 
> On 4/23/19 2:39 PM, Artem Mygaiev wrote:
> > Hello Julien, Roger
> > 
> > On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
> > > (+ Roger)
> > > 
> > > On 18/04/2019 12:15, Artem Mygaiev wrote:
> > > > Hi Julien
> > > > 
> > > > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > > > Hello Julien, Stefano
> > > > > 
> > > > > Hi Artem,
> > > > > 
> > > > > > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > > > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > > > > > Hi Julien,
> > > > > > > > > 
> > > > > > > > > Hi Artem,
> > > > > > > > > 
> > > > > > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall
> > > > > > > > > > wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > > 
> > > > > > > > > > > This series adds support to build Xen Arm with
> > > > > > > > > > > clang.
> > > > > > > > > > > This series was
> > > > > > > > > > > tested
> > > > > > > > > > > with clang 8.0.
> > > > > > > > > > > 
> > > > > > > > > > > Note that I only did build for arm64. I still
> > > > > > > > > > > need to
> > > > > > > > > > > look at the arm32
> > > > > > > > > > > build.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I wonder if you have time to try the series with
> > > > > > > > > > Arm
> > > > > > > > > > Compiler 6? I am
> > > > > > > > > > asking because AFAIK it is based on clang/llvm [1]
> > > > > > > > > > and
> > > > > > > > > > there's a
> > > > > > > > > > safety-compliant version of it certified by TUV
> > > > > > > > > > [2]. I
> > > > > > > > > > don't have a
> > > > > > > > > > license yet so cannot try it myself but maybe you
> > > > > > > > > > have
> > > > > > > > > > access.
> > > > > > > > > 
> > > > > > > > > I gave a quick try to the Arm Compiler. I had to hack
> > > > > > > > > a
> > > > > > > > > bit
> > > > > > > > > config/StdGNU.mk
> > > > > > > > > to pass armclang and the appropriate target option.
> > > > > > > > > 
> > > > > > > > > I also had a linking issue at the end where
> > > > > > > > > __2snprintf
> > > > > > > > > was
> > > > > > > > > not found. It
> > > > > > > > > seems the compiler replace snprintf with __2snprintf,
> > > > > > > > > I
> > > > > > > > > haven't figured out
> > > > > > > > > why yet.
> > > > > > > > 
> > > > > > > > But after these changes, does it work?
> > > > > > > 
> > > > > > > I haven't tried to fix the linking issues. I only gave a
> > > > > > > quick
> > > > > > > try because Artem
> > > > > > > asked. I have no plan at the moment to go further than
> > > > > > > that
> > > > > > > for
> > > > > > > now.
> > > > > > > 
> > > > > > > Patches are welcomed to add support for armclang.
> > > > > > > 
> > > > > > 
> > > > > > I have implemented a bunch of HACKs [1] so can build Xen
> > > > > > master
> > > > > > with
> > > > > > armclang 6.12. Not even "smoke"-tested, just trying to
> > > > > > identify
> > > > > > missing
> > > > > > parameters and proper linker configuration.
> > > > > 
> > > > > Thank you for looking at it. Some comments below.
> > > > > 
> > > > > > Not yet fixed section placement, lots of warnings from
> > > > > > linker
> > > > > > like:
> > > > > > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > > > > > .altinstr_replacement(ns16550.o:42) identifies code, but is
> > > > > > in
> > > > > > a
> > > > > > section not marked as executable.
> > > > > 
> > > > > Instruction in the sections .altinstr_replacement are never
> > > > > meant
> > > > > to
> > > > > be executed.
> > > > > 
> > > > > I guess this is coming from armlink? Any particular reason to
> > > > > use
> > > > > armlink and
> > > > > not ld as we do on clang?
> > > > > 
> > > > 
> > > > Yes, armlink has a "Safety-certified" version of it, while ld
> > > > doesn't,
> > > > unfortunately :(
> > > 
> > > I am not sure if anyone tried to build Xen other than with ld so
> > > far.
> > > I have
> > > CCed Roger who might have a clue whether there are other blocker.
> > > 
> > 
> > Looking forward to hearing from Roger.
> > 
> > > > Though I must mention that I do not have access to safety-
> > > > certified
> > > > version of arm compiler suite, it is not public. Thus checking
> > > > only
> > > > against the 30-day trial version of ARM DS 2019-0 which is
> > > > shipped
> > > > with
> > > > compiler 6.12
> > > 
> > > Any step towards armclang is good :). We can look at the safety-
> > > certified
> > > version afterwards.
> > > 
> > > I don't seem to be able to link with this patch on 6.12:
> > > 
> > > Loading object built_in.o.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > 
> > > I am using the following command line to build:
> > > 
> > > 42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64
> > > clang=y
> > > armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y
> > > 
> > 
> > I am still struggling with linker internal fault, not sure what
> > changed
> > in my environment so it started to fail.
> > 
> > > > > > Also armlink sometimes fails with Internal fault:
> > > > > > [0xe81a5a:6120001]
> > > > > 
> > > > > Do you have more output?
> > > > 
> > > > Just opened a ticket in Arm community forums, see details there
> > > > including full build log (dont want to spam ml)
> > > > https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001
> > > > 
> > > > 
> > > 
> > > There are nothing interesting in except a flood of "armclang:
> > > warning: Your
> > > license for feature ds_suite_eval will expire in 29 days".
> > > 
> > > Let me know how it goes and I can help to resolve it.
> > > 
> > 
> > This is because of the "free" evaluation license I have, probably
> > can
> > be safely ignored.
> 
> I know :). I was pointed out how verbose it was compare to the lack
> of 
> information regarding the internal fault.
> 
> > So far no reaction on my initial post in Arm Community.
> > 
> > Playing with linker options I found that the error is caused by the
> > use
> > of "partial linking model" which is enabled by --partial that
> > correspond to -r in Xen Makefiles, which is not documented but has
> > similar effect.
> 
> Do you mean the "Internal Fault"?
> 

Yes.

But I kinda sorted this issue out. That was a dumb mistake - while
working I have moved to a different code tree that I used to check gcov
so it had CONFIG_COVERAGE enabled. I got rid of linker internal fault
after disabling it (though still not clear why this led to linker
failing with -r)

Now I am getting the same linker error you mentioned. Will continue
working on this after holidays, suspect that armlink missing proper
configuration and probably section placement.

> > > > > > [1] Diff below just for reference with xen master +
> > > > > > Julien's
> > > > > > clang
> > > > > > patch series applied
> > > > > > ---
> > > > > > 
> > > > > > diff --git a/Config.mk b/Config.mk
> > > > > > index 417039d7f6..0fc84293f9 100644
> > > > > > --- a/Config.mk
> > > > > > +++ b/Config.mk
> > > > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> > > > > >     
> > > > > >     $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-OW 
> > > > > > aft
> > > > > > statement)
> > > > > >     $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-
> > > > > > statement)
> > > > > > +ifneq ($(armds),y)
> > > > > >     $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-
> > > > > > variable)
> > > > > 
> > > > > I didn't need this on Arm Compiler 6.11. Can you provide the
> > > > > list
> > > > > of
> > > > > error you
> > > > > get here?
> > > > 
> > > > error: unknown warning option '-Wno-unused-but-set-variable';
> > > > did
> > > > you
> > > > mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-
> > > > option]
> > > 
> > > But cc-option-add should only add the flag if it is supported by
> > > the
> > > compiler.
> > > So it is not supported, how come this option is actually used to
> > > compile?
> > > 
> > 
> > Because the idea of supported option detection rely on the fact
> > that
> > compiler will throw an error or warning when makefile try and use
> > the
> > option being tested, but armclang does not even try to check that
> > and
> > failing with
> >    armclang: fatal error: no target architecture given; use --
> > target=arm-arm-none-eabi or --target=aarch64-arm-none-eabi
> > and thus cc-option-add does not detect unsupported options
> 
> I think defining CC as below should do the trick:
> 
> CC := armclang --target=aarch64-arm-none-eabi
> 

Agree

> > > > > > +endif
> > > > > >     $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-
> > > > > > typedefs)
> > > > > >     
> > > > > >     LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > > > > > @@ -234,9 +236,15 @@ endif
> > > > > >     APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
> > > > > >     APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES),
> > > > > > -I$(i))
> > > > > >     
> > > > > > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-
> > > > > > stack-
> > > > > > protector-all
> > > > > > +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
> > > > > > protector-all
> > > > > >     EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> > > > > >     
> > > > > > +ifeq ($(armds),y)
> > > > > > +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
> > > > > 
> > > > > Why do you need this? Is it because armlink does not support
> > > > > -nopie?
> > > > 
> > > > Yes. ropi/rwpi are according to Arm Compiler 6.12 reference
> > > > guide,
> > > > see
> > > > [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]
> > > 
> > > Hmmm, but the docs says:
> > > 
> > > "This option is not supported in AArch64 state". So is that a
> > > really
> > > good
> > > replacement?
> > > 
> > 
> > You're right, reading further in the document this does not seem to
> > be
> > a valid replacement. Moreover, it seems that we dont need this
> > option
> > with armclang - by default it does not generate position-
> > independent
> > code
> 
> As this always been the case? I know that for GCC it depends on the
> on 
> distro/version of the compiler.

I will check how armclang implements this later on.

> 
> > > [...]
> > > 
> > > > > You would still need --target=.... but that's should depend
> > > > > on
> > > > > $CROSS_COMPILE
> > > > > (or any other name we decide).
> > > > 
> > > > You're right, I forgot to mention - have not yet built for
> > > > Arm32 so
> > > > this is not checked. But, according to manual:
> > > > 
> > > > For targets in AArch32 state (--target=arm-arm-none-eabi),
> > > > there is
> > > > no
> > > > default. You must specify either -march (to target an
> > > > architecture)
> > > > or
> > > > -mcpu (to target a processor)
> > > 
> > > We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit
> > > that
> > > cortex-a15
> > > is probably not the most suitable). If some options should
> > > applied to
> > > the tools
> > > as well, then we need to migrated them to config/arm32.mk.
> > 
> > Yes, I do not think we shall specify the particular CPU, better to
> > have
> > lowest supported architecture defined.
> 
> I vaguely remembered to try to replace cortex-a15 with something else
> in 
> the past. IIRC, the problem was armv7-a does not necessarily include 
> virt extension.
> 
> Trying again today with -march=armv7-a instead of -mcpu=cortex-a15,
> I 
> can see build error when using Linaro GCC 6.1-2016.80:
> 
> {standard input}: Assembler messages:
> {standard input}:285: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> {standard input}:429: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> {standard input}:462: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> {standard input}:539: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> /home/julieng/works/xen/xen/Rules.mk:196: recipe for target 
> 'cpuerrata.o' failed
> make[3]: *** [cpuerrata.o] Error 1
> 
> I think this one is solvable by specifying the secure extension. But
> it 
> might be possible there are other issues with older compiler (i.e 4.6
> & co).
> 

Could be. We might need do do automatic checks with old compilers

> > > > [100067_0612_00_en page 1-82]
> > > > 
> > > > > > +else
> > > > > > +CFLAGS += -marm # -march= -mcpu=
> > > > > >     # Use only if calling $(LD) directly.
> > > > > >     LDFLAGS_DIRECT += -EL
> > > > > > +endif
> > > > > >     
> > > > > >     IOEMU_CPU_ARCH ?= arm
> > > > > > diff --git a/config/arm64.mk b/config/arm64.mk
> > > > > > index aa45772b61..46b203d384 100644
> > > > > > --- a/config/arm64.mk
> > > > > > +++ b/config/arm64.mk
> > > > > > @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> > > > > >     
> > > > > >     CONFIG_XEN_INSTALL_SUFFIX :=
> > > > > >     
> > > > > > +ifeq ($(armds),y)
> > > > > > +# VE needed
> > > > > > +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
> > > > > > a+nofp+nosimd
> > > > > 
> > > > > Same remark for --target.
> > > > > Also, -march=armv8.1 looks wrong to me because this may
> > > > > generate
> > > > > code
> > > > > that will
> > > > > not work on armv8.0 platform.
> > > > > 
> > > > 
> > > > If I don't specify -march this way, it will built:
> > > >    1) without some registers, e.g. TTLB0_EL2 support (build
> > > > fails)
> > > 
> > > I guess you mean TTBR0_EL2 here.
> > > 
> > > Xen is fully Armv8.0 compliant. So if you can't compile Xen with
> > > -march=armv8-a
> > > then this needs to be investigated and be reported.
> > > 
> > > Looking at the error thrown:
> > > 
> > > arm64/head.S:399:13: error: expected writable system register or
> > > pstate
> > >           msr TTBR0_EL2, x4
> > > 
> > > This is likely a compiler bug.
> > > 
> > 
> > Actually I do not know what is the proper way to report such issues
> > and
> > get them fixed. My post on ARM forum regarding linker failue has no
> > comments/reactions, which means it may not be the best way for
> > reporting. Would it be possible for you to check if we can get some
> > attention from ARM Compiler folks?
> 
> I will have a chat and let you know.
> 
> > > >    2) with vfp and simd enabled (linking fails)
> > > > 
> > > > According to Arm compiler manual:
> > > > ---
> > > > For targets in AArch64 state (--target=aarch64-arm-none-eabi),
> > > > unless
> > > > you target a particular processor using -mcpu or a particular
> > > > architecture using -march, the compiler defaults to
> > > > -march=armv8-a,
> > > > generating generic code for Armv8‑A in AArch64 state.
> > > > [100067_0612_00_en page 1-82]
> > > > ---
> > > > You can prevent the use of floating-point instructions or
> > > > floating-
> > > > point registers for targets in AArch64 state with the
> > > > -mcpu=name+nofp+nosimd option. Subsequent use of floating-point
> > > > data
> > > > types in this mode is unsupported.
> > > > [100067_0612_00_en page 1-93]
> > > > ---
> > > 
> > > I assume that -mgeneral-regs-only does not work in your case?
> > 
> > Nope :\
> 
> It would be interesting to know whether -march=armv8-a... works on
> all 
> GCC version we support.
> 
> Cheers,
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Artem Mygaiev]

Hello Julien

On Wed, 2019-04-24 at 22:07 +0100, Julien Grall wrote:
> Hi Artem,
> 
> On 4/23/19 2:39 PM, Artem Mygaiev wrote:
> > Hello Julien, Roger
> > 
> > On Thu, 2019-04-18 at 19:33 +0100, Julien Grall wrote:
> > > (+ Roger)
> > > 
> > > On 18/04/2019 12:15, Artem Mygaiev wrote:
> > > > Hi Julien
> > > > 
> > > > On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> > > > > On 18/04/2019 10:15, Artem Mygaiev wrote:
> > > > > > Hello Julien, Stefano
> > > > > 
> > > > > Hi Artem,
> > > > > 
> > > > > > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > > > > > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > > > > > > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > > > > > > > Hi Julien,
> > > > > > > > > 
> > > > > > > > > Hi Artem,
> > > > > > > > > 
> > > > > > > > > > On Wed, 2019-03-27 at 18:45 +0000, Julien Grall
> > > > > > > > > > wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > > 
> > > > > > > > > > > This series adds support to build Xen Arm with
> > > > > > > > > > > clang.
> > > > > > > > > > > This series was
> > > > > > > > > > > tested
> > > > > > > > > > > with clang 8.0.
> > > > > > > > > > > 
> > > > > > > > > > > Note that I only did build for arm64. I still
> > > > > > > > > > > need to
> > > > > > > > > > > look at the arm32
> > > > > > > > > > > build.
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I wonder if you have time to try the series with
> > > > > > > > > > Arm
> > > > > > > > > > Compiler 6? I am
> > > > > > > > > > asking because AFAIK it is based on clang/llvm [1]
> > > > > > > > > > and
> > > > > > > > > > there's a
> > > > > > > > > > safety-compliant version of it certified by TUV
> > > > > > > > > > [2]. I
> > > > > > > > > > don't have a
> > > > > > > > > > license yet so cannot try it myself but maybe you
> > > > > > > > > > have
> > > > > > > > > > access.
> > > > > > > > > 
> > > > > > > > > I gave a quick try to the Arm Compiler. I had to hack
> > > > > > > > > a
> > > > > > > > > bit
> > > > > > > > > config/StdGNU.mk
> > > > > > > > > to pass armclang and the appropriate target option.
> > > > > > > > > 
> > > > > > > > > I also had a linking issue at the end where
> > > > > > > > > __2snprintf
> > > > > > > > > was
> > > > > > > > > not found. It
> > > > > > > > > seems the compiler replace snprintf with __2snprintf,
> > > > > > > > > I
> > > > > > > > > haven't figured out
> > > > > > > > > why yet.
> > > > > > > > 
> > > > > > > > But after these changes, does it work?
> > > > > > > 
> > > > > > > I haven't tried to fix the linking issues. I only gave a
> > > > > > > quick
> > > > > > > try because Artem
> > > > > > > asked. I have no plan at the moment to go further than
> > > > > > > that
> > > > > > > for
> > > > > > > now.
> > > > > > > 
> > > > > > > Patches are welcomed to add support for armclang.
> > > > > > > 
> > > > > > 
> > > > > > I have implemented a bunch of HACKs [1] so can build Xen
> > > > > > master
> > > > > > with
> > > > > > armclang 6.12. Not even "smoke"-tested, just trying to
> > > > > > identify
> > > > > > missing
> > > > > > parameters and proper linker configuration.
> > > > > 
> > > > > Thank you for looking at it. Some comments below.
> > > > > 
> > > > > > Not yet fixed section placement, lots of warnings from
> > > > > > linker
> > > > > > like:
> > > > > > Warning: L6170W: Mapping symbol #40 '$x.20' in
> > > > > > .altinstr_replacement(ns16550.o:42) identifies code, but is
> > > > > > in
> > > > > > a
> > > > > > section not marked as executable.
> > > > > 
> > > > > Instruction in the sections .altinstr_replacement are never
> > > > > meant
> > > > > to
> > > > > be executed.
> > > > > 
> > > > > I guess this is coming from armlink? Any particular reason to
> > > > > use
> > > > > armlink and
> > > > > not ld as we do on clang?
> > > > > 
> > > > 
> > > > Yes, armlink has a "Safety-certified" version of it, while ld
> > > > doesn't,
> > > > unfortunately :(
> > > 
> > > I am not sure if anyone tried to build Xen other than with ld so
> > > far.
> > > I have
> > > CCed Roger who might have a clue whether there are other blocker.
> > > 
> > 
> > Looking forward to hearing from Roger.
> > 
> > > > Though I must mention that I do not have access to safety-
> > > > certified
> > > > version of arm compiler suite, it is not public. Thus checking
> > > > only
> > > > against the 30-day trial version of ARM DS 2019-0 which is
> > > > shipped
> > > > with
> > > > compiler 6.12
> > > 
> > > Any step towards armclang is good :). We can look at the safety-
> > > certified
> > > version afterwards.
> > > 
> > > I don't seem to be able to link with this patch on 6.12:
> > > 
> > > Loading object built_in.o.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > Error: L6242E: Cannot link object built_in.o as its attributes
> > > are
> > > incompatible
> > > with the image attributes.
> > >      ... A64 clashes with SoftVFP.
> > > 
> > > I am using the following command line to build:
> > > 
> > > 42sh> make CROSS_COMPILE=aarch64-linux-gnu- XEN_TARGET_ARCH=arm64
> > > clang=y
> > > armds=y  -C ~/works/xen/xen  XEN_CONFIG_EXPERT=y
> > > 
> > 
> > I am still struggling with linker internal fault, not sure what
> > changed
> > in my environment so it started to fail.
> > 
> > > > > > Also armlink sometimes fails with Internal fault:
> > > > > > [0xe81a5a:6120001]
> > > > > 
> > > > > Do you have more output?
> > > > 
> > > > Just opened a ticket in Arm community forums, see details there
> > > > including full build log (dont want to spam ml)
> > > > https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/12989/linker-internal-fault-0xe81a5a-6120001
> > > > 
> > > > 
> > > 
> > > There are nothing interesting in except a flood of "armclang:
> > > warning: Your
> > > license for feature ds_suite_eval will expire in 29 days".
> > > 
> > > Let me know how it goes and I can help to resolve it.
> > > 
> > 
> > This is because of the "free" evaluation license I have, probably
> > can
> > be safely ignored.
> 
> I know :). I was pointed out how verbose it was compare to the lack
> of 
> information regarding the internal fault.
> 
> > So far no reaction on my initial post in Arm Community.
> > 
> > Playing with linker options I found that the error is caused by the
> > use
> > of "partial linking model" which is enabled by --partial that
> > correspond to -r in Xen Makefiles, which is not documented but has
> > similar effect.
> 
> Do you mean the "Internal Fault"?
> 

Yes.

But I kinda sorted this issue out. That was a dumb mistake - while
working I have moved to a different code tree that I used to check gcov
so it had CONFIG_COVERAGE enabled. I got rid of linker internal fault
after disabling it (though still not clear why this led to linker
failing with -r)

Now I am getting the same linker error you mentioned. Will continue
working on this after holidays, suspect that armlink missing proper
configuration and probably section placement.

> > > > > > [1] Diff below just for reference with xen master +
> > > > > > Julien's
> > > > > > clang
> > > > > > patch series applied
> > > > > > ---
> > > > > > 
> > > > > > diff --git a/Config.mk b/Config.mk
> > > > > > index 417039d7f6..0fc84293f9 100644
> > > > > > --- a/Config.mk
> > > > > > +++ b/Config.mk
> > > > > > @@ -221,7 +221,9 @@ CFLAGS += -Wall -Wstrict-prototypes
> > > > > >     
> > > > > >     $(call cc-option-add,HOSTCFLAGS,HOSTCC,-Wdeclaration-OW 
> > > > > > aft
> > > > > > statement)
> > > > > >     $(call cc-option-add,CFLAGS,CC,-Wdeclaration-after-
> > > > > > statement)
> > > > > > +ifneq ($(armds),y)
> > > > > >     $(call cc-option-add,CFLAGS,CC,-Wno-unused-but-set-
> > > > > > variable)
> > > > > 
> > > > > I didn't need this on Arm Compiler 6.11. Can you provide the
> > > > > list
> > > > > of
> > > > > error you
> > > > > get here?
> > > > 
> > > > error: unknown warning option '-Wno-unused-but-set-variable';
> > > > did
> > > > you
> > > > mean '-Wno-unused-const-variable'? [-Werror,-Wunknown-warning-
> > > > option]
> > > 
> > > But cc-option-add should only add the flag if it is supported by
> > > the
> > > compiler.
> > > So it is not supported, how come this option is actually used to
> > > compile?
> > > 
> > 
> > Because the idea of supported option detection rely on the fact
> > that
> > compiler will throw an error or warning when makefile try and use
> > the
> > option being tested, but armclang does not even try to check that
> > and
> > failing with
> >    armclang: fatal error: no target architecture given; use --
> > target=arm-arm-none-eabi or --target=aarch64-arm-none-eabi
> > and thus cc-option-add does not detect unsupported options
> 
> I think defining CC as below should do the trick:
> 
> CC := armclang --target=aarch64-arm-none-eabi
> 

Agree

> > > > > > +endif
> > > > > >     $(call cc-option-add,CFLAGS,CC,-Wno-unused-local-
> > > > > > typedefs)
> > > > > >     
> > > > > >     LDFLAGS += $(foreach i, $(EXTRA_LIB), -L$(i))
> > > > > > @@ -234,9 +236,15 @@ endif
> > > > > >     APPEND_LDFLAGS += $(foreach i, $(APPEND_LIB), -L$(i))
> > > > > >     APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES),
> > > > > > -I$(i))
> > > > > >     
> > > > > > -EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-
> > > > > > stack-
> > > > > > protector-all
> > > > > > +EMBEDDED_EXTRA_CFLAGS := -fno-stack-protector -fno-stack-
> > > > > > protector-all
> > > > > >     EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
> > > > > >     
> > > > > > +ifeq ($(armds),y)
> > > > > > +EMBEDDED_EXTRA_CFLAGS += -fno-ropi -fno-rwpi
> > > > > 
> > > > > Why do you need this? Is it because armlink does not support
> > > > > -nopie?
> > > > 
> > > > Yes. ropi/rwpi are according to Arm Compiler 6.12 reference
> > > > guide,
> > > > see
> > > > [100067_0612_00_en 1-54] and [100067_0612_00_en 1-56]
> > > 
> > > Hmmm, but the docs says:
> > > 
> > > "This option is not supported in AArch64 state". So is that a
> > > really
> > > good
> > > replacement?
> > > 
> > 
> > You're right, reading further in the document this does not seem to
> > be
> > a valid replacement. Moreover, it seems that we dont need this
> > option
> > with armclang - by default it does not generate position-
> > independent
> > code
> 
> As this always been the case? I know that for GCC it depends on the
> on 
> distro/version of the compiler.

I will check how armclang implements this later on.

> 
> > > [...]
> > > 
> > > > > You would still need --target=.... but that's should depend
> > > > > on
> > > > > $CROSS_COMPILE
> > > > > (or any other name we decide).
> > > > 
> > > > You're right, I forgot to mention - have not yet built for
> > > > Arm32 so
> > > > this is not checked. But, according to manual:
> > > > 
> > > > For targets in AArch32 state (--target=arm-arm-none-eabi),
> > > > there is
> > > > no
> > > > default. You must specify either -march (to target an
> > > > architecture)
> > > > or
> > > > -mcpu (to target a processor)
> > > 
> > > We actually pass -mcpu=cortex-a15 in arch/arm/Rules.mk (I admit
> > > that
> > > cortex-a15
> > > is probably not the most suitable). If some options should
> > > applied to
> > > the tools
> > > as well, then we need to migrated them to config/arm32.mk.
> > 
> > Yes, I do not think we shall specify the particular CPU, better to
> > have
> > lowest supported architecture defined.
> 
> I vaguely remembered to try to replace cortex-a15 with something else
> in 
> the past. IIRC, the problem was armv7-a does not necessarily include 
> virt extension.
> 
> Trying again today with -march=armv7-a instead of -mcpu=cortex-a15,
> I 
> can see build error when using Linaro GCC 6.1-2016.80:
> 
> {standard input}: Assembler messages:
> {standard input}:285: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> {standard input}:429: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> {standard input}:462: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> {standard input}:539: Error: selected processor does not support
> `smc 
> #0' in ARM mode
> /home/julieng/works/xen/xen/Rules.mk:196: recipe for target 
> 'cpuerrata.o' failed
> make[3]: *** [cpuerrata.o] Error 1
> 
> I think this one is solvable by specifying the secure extension. But
> it 
> might be possible there are other issues with older compiler (i.e 4.6
> & co).
> 

Could be. We might need do do automatic checks with old compilers

> > > > [100067_0612_00_en page 1-82]
> > > > 
> > > > > > +else
> > > > > > +CFLAGS += -marm # -march= -mcpu=
> > > > > >     # Use only if calling $(LD) directly.
> > > > > >     LDFLAGS_DIRECT += -EL
> > > > > > +endif
> > > > > >     
> > > > > >     IOEMU_CPU_ARCH ?= arm
> > > > > > diff --git a/config/arm64.mk b/config/arm64.mk
> > > > > > index aa45772b61..46b203d384 100644
> > > > > > --- a/config/arm64.mk
> > > > > > +++ b/config/arm64.mk
> > > > > > @@ -4,10 +4,14 @@ CONFIG_ARM_$(XEN_OS) := y
> > > > > >     
> > > > > >     CONFIG_XEN_INSTALL_SUFFIX :=
> > > > > >     
> > > > > > +ifeq ($(armds),y)
> > > > > > +# VE needed
> > > > > > +CFLAGS += --target=aarch64-arm-none-eabi -march=armv8.1-
> > > > > > a+nofp+nosimd
> > > > > 
> > > > > Same remark for --target.
> > > > > Also, -march=armv8.1 looks wrong to me because this may
> > > > > generate
> > > > > code
> > > > > that will
> > > > > not work on armv8.0 platform.
> > > > > 
> > > > 
> > > > If I don't specify -march this way, it will built:
> > > >    1) without some registers, e.g. TTLB0_EL2 support (build
> > > > fails)
> > > 
> > > I guess you mean TTBR0_EL2 here.
> > > 
> > > Xen is fully Armv8.0 compliant. So if you can't compile Xen with
> > > -march=armv8-a
> > > then this needs to be investigated and be reported.
> > > 
> > > Looking at the error thrown:
> > > 
> > > arm64/head.S:399:13: error: expected writable system register or
> > > pstate
> > >           msr TTBR0_EL2, x4
> > > 
> > > This is likely a compiler bug.
> > > 
> > 
> > Actually I do not know what is the proper way to report such issues
> > and
> > get them fixed. My post on ARM forum regarding linker failue has no
> > comments/reactions, which means it may not be the best way for
> > reporting. Would it be possible for you to check if we can get some
> > attention from ARM Compiler folks?
> 
> I will have a chat and let you know.
> 
> > > >    2) with vfp and simd enabled (linking fails)
> > > > 
> > > > According to Arm compiler manual:
> > > > ---
> > > > For targets in AArch64 state (--target=aarch64-arm-none-eabi),
> > > > unless
> > > > you target a particular processor using -mcpu or a particular
> > > > architecture using -march, the compiler defaults to
> > > > -march=armv8-a,
> > > > generating generic code for Armv8‑A in AArch64 state.
> > > > [100067_0612_00_en page 1-82]
> > > > ---
> > > > You can prevent the use of floating-point instructions or
> > > > floating-
> > > > point registers for targets in AArch64 state with the
> > > > -mcpu=name+nofp+nosimd option. Subsequent use of floating-point
> > > > data
> > > > types in this mode is unsupported.
> > > > [100067_0612_00_en page 1-93]
> > > > ---
> > > 
> > > I assume that -mgeneral-regs-only does not work in your case?
> > 
> > Nope :\
> 
> It would be interesting to know whether -march=armv8-a... works on
> all 
> GCC version we support.
> 
> Cheers,
> 
> 
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Julien Grall]

Hi,

Sorry, I am picking up this series again.

On 4/18/19 7:03 PM, Stefano Stabellini wrote:
> On Wed, 17 Apr 2019, Julien Grall wrote:
>> Hi,
>>
>> On 4/17/19 9:45 PM, Stefano Stabellini wrote:
>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>>>> Clang understands the GCCism in use here, but still complains that sp is
>>>> unitialised. In such cases, resort to the older versions of this code,
>>>> which directly read sp into the temporary variable.
>>>>
>>>> Note that we still keep the GCCism in the default case, as it causes GCC
>>>> to create rather better assembly.
>>>>
>>>> This is based on the x86 counterpart.
>>>
>>> I understand this is based on an existing approach but what about other
>>> compilers? I have a suggestion below.
>>
>> What if the compiler actually support named registers? Why would we make the
>> code less efficient?
> 
> It is not my intention to make the code less efficient for other
> compilers. However, reading the commit message and the patch I have the
> impression that the clang version is more likely to be applicable to
> other compilers, compared to the gcc version. More "standard". The
> reason is that the clang version only requires asm inline, while the gcc
> version requires both asm inline and named registers. For the sake of
> getting Xen to compile out of the box with any C compiler, I think it is
> best if we default to the less demanding version of the implementation
> for unknown compilers.
While building Xen out of box is nice goal to have, this is likely be 
very hard to reach out because Xen is using a lot of GCCism. It mostly 
work with Clang because they have adopted some of them.

I would be happy to revert the condition, but then AFAICT there are no 
pretty way to now that we are using GCC. While the define __GNUC__ is 
meant to tell you this is compiled with GCC, clang is also defining it.

So the condition would have to be

#if !defined(__clang__) && defined(__GNUC__)

But then if clang is already defining __GNUC__, what actually prevents 
any other to do it?

I have yet to see anyone wanted to build Xen with another compiler other 
than clang and GCC. So I will leave this patch as is. Feel free to 
suggest a different approach if you are not happy with this.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Stefano Stabellini]

On Sun, 29 Sep 2019, Julien Grall wrote:
> Hi,
> 
> Sorry, I am picking up this series again.
> 
> On 4/18/19 7:03 PM, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Clang understands the GCCism in use here, but still complains that sp
> > > > > is
> > > > > unitialised. In such cases, resort to the older versions of this code,
> > > > > which directly read sp into the temporary variable.
> > > > > 
> > > > > Note that we still keep the GCCism in the default case, as it causes
> > > > > GCC
> > > > > to create rather better assembly.
> > > > > 
> > > > > This is based on the x86 counterpart.
> > > > 
> > > > I understand this is based on an existing approach but what about other
> > > > compilers? I have a suggestion below.
> > > 
> > > What if the compiler actually support named registers? Why would we make
> > > the
> > > code less efficient?
> > 
> > It is not my intention to make the code less efficient for other
> > compilers. However, reading the commit message and the patch I have the
> > impression that the clang version is more likely to be applicable to
> > other compilers, compared to the gcc version. More "standard". The
> > reason is that the clang version only requires asm inline, while the gcc
> > version requires both asm inline and named registers. For the sake of
> > getting Xen to compile out of the box with any C compiler, I think it is
> > best if we default to the less demanding version of the implementation
> > for unknown compilers.
> While building Xen out of box is nice goal to have, this is likely be very
> hard to reach out because Xen is using a lot of GCCism. It mostly work with
> Clang because they have adopted some of them.
> 
> I would be happy to revert the condition, but then AFAICT there are no pretty
> way to now that we are using GCC. While the define __GNUC__ is meant to tell
> you this is compiled with GCC, clang is also defining it.

That's horrible, I didn't know about that!


> So the condition would have to be
> 
> #if !defined(__clang__) && defined(__GNUC__)

:-(


> But then if clang is already defining __GNUC__, what actually prevents any
> other to do it?
> 
> I have yet to see anyone wanted to build Xen with another compiler other than
> clang and GCC. So I will leave this patch as is. Feel free to suggest a
> different approach if you are not happy with this.

Is there a __REALLY_REALLY_GUNC__ variable? I guess not, so I don't have
a better suggestion. This problem is quite annoying (not your fault of
course) I wonder how other projects deal with it. There must be a
"clean" way to distinguish gcc from others?

For now, I am OK with this patch as is because I wouldn't know what else
to suggest, and I agree that !defined(__clang__) && defined(__GNUC__) is
bad.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Stefano Stabellini]

On Mon, 30 Sep 2019, Stefano Stabellini wrote:
> On Sun, 29 Sep 2019, Julien Grall wrote:
> > Hi,
> > 
> > Sorry, I am picking up this series again.
> > 
> > On 4/18/19 7:03 PM, Stefano Stabellini wrote:
> > > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > > Hi,
> > > > 
> > > > On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> > > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > > Clang understands the GCCism in use here, but still complains that sp
> > > > > > is
> > > > > > unitialised. In such cases, resort to the older versions of this code,
> > > > > > which directly read sp into the temporary variable.
> > > > > > 
> > > > > > Note that we still keep the GCCism in the default case, as it causes
> > > > > > GCC
> > > > > > to create rather better assembly.
> > > > > > 
> > > > > > This is based on the x86 counterpart.
> > > > > 
> > > > > I understand this is based on an existing approach but what about other
> > > > > compilers? I have a suggestion below.
> > > > 
> > > > What if the compiler actually support named registers? Why would we make
> > > > the
> > > > code less efficient?
> > > 
> > > It is not my intention to make the code less efficient for other
> > > compilers. However, reading the commit message and the patch I have the
> > > impression that the clang version is more likely to be applicable to
> > > other compilers, compared to the gcc version. More "standard". The
> > > reason is that the clang version only requires asm inline, while the gcc
> > > version requires both asm inline and named registers. For the sake of
> > > getting Xen to compile out of the box with any C compiler, I think it is
> > > best if we default to the less demanding version of the implementation
> > > for unknown compilers.
> > While building Xen out of box is nice goal to have, this is likely be very
> > hard to reach out because Xen is using a lot of GCCism. It mostly work with
> > Clang because they have adopted some of them.
> > 
> > I would be happy to revert the condition, but then AFAICT there are no pretty
> > way to now that we are using GCC. While the define __GNUC__ is meant to tell
> > you this is compiled with GCC, clang is also defining it.
> 
> That's horrible, I didn't know about that!
> 
> 
> > So the condition would have to be
> > 
> > #if !defined(__clang__) && defined(__GNUC__)
> 
> :-(
> 
> 
> > But then if clang is already defining __GNUC__, what actually prevents any
> > other to do it?
> > 
> > I have yet to see anyone wanted to build Xen with another compiler other than
> > clang and GCC. So I will leave this patch as is. Feel free to suggest a
> > different approach if you are not happy with this.
> 
> Is there a __REALLY_REALLY_GUNC__ variable? I guess not, so I don't have
> a better suggestion. This problem is quite annoying (not your fault of
> course) I wonder how other projects deal with it. There must be a
> "clean" way to distinguish gcc from others?
> 
> For now, I am OK with this patch as is because I wouldn't know what else
> to suggest, and I agree that !defined(__clang__) && defined(__GNUC__) is
> bad.

and you can add:

Acked-by: Stefano Stabellini <sstabellini@kernel.org>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Julien Grall]

Hi,

On 01/10/2019 02:15, Stefano Stabellini wrote:
> On Sun, 29 Sep 2019, Julien Grall wrote:
>> On 4/18/19 7:03 PM, Stefano Stabellini wrote:
>>> On Wed, 17 Apr 2019, Julien Grall wrote:
>>>> On 4/17/19 9:45 PM, Stefano Stabellini wrote:
>>>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>> But then if clang is already defining __GNUC__, what actually prevents any
>> other to do it?
>>
>> I have yet to see anyone wanted to build Xen with another compiler other than
>> clang and GCC. So I will leave this patch as is. Feel free to suggest a
>> different approach if you are not happy with this.
> 
> Is there a __REALLY_REALLY_GUNC__ variable? I guess not, so I don't have
> a better suggestion. This problem is quite annoying (not your fault of
> course) I wonder how other projects deal with it. There must be a
> "clean" way to distinguish gcc from others?

Linux only supports clang and GCC. AFAICT they are using !__clang__ to detect if 
GCC is used.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 02/12] xen/arm: fix get_cpu_info() when built with clang

[Julien Grall]

On 01/10/2019 02:22, Stefano Stabellini wrote:
> On Mon, 30 Sep 2019, Stefano Stabellini wrote:
>> On Sun, 29 Sep 2019, Julien Grall wrote:
>>> Hi,
>>>
>>> Sorry, I am picking up this series again.
>>>
>>> On 4/18/19 7:03 PM, Stefano Stabellini wrote:
>>>> On Wed, 17 Apr 2019, Julien Grall wrote:
>>>>> Hi,
>>>>>
>>>>> On 4/17/19 9:45 PM, Stefano Stabellini wrote:
>>>>>> On Wed, 27 Mar 2019, Julien Grall wrote:
>>>>>>> Clang understands the GCCism in use here, but still complains that sp
>>>>>>> is
>>>>>>> unitialised. In such cases, resort to the older versions of this code,
>>>>>>> which directly read sp into the temporary variable.
>>>>>>>
>>>>>>> Note that we still keep the GCCism in the default case, as it causes
>>>>>>> GCC
>>>>>>> to create rather better assembly.
>>>>>>>
>>>>>>> This is based on the x86 counterpart.
>>>>>>
>>>>>> I understand this is based on an existing approach but what about other
>>>>>> compilers? I have a suggestion below.
>>>>>
>>>>> What if the compiler actually support named registers? Why would we make
>>>>> the
>>>>> code less efficient?
>>>>
>>>> It is not my intention to make the code less efficient for other
>>>> compilers. However, reading the commit message and the patch I have the
>>>> impression that the clang version is more likely to be applicable to
>>>> other compilers, compared to the gcc version. More "standard". The
>>>> reason is that the clang version only requires asm inline, while the gcc
>>>> version requires both asm inline and named registers. For the sake of
>>>> getting Xen to compile out of the box with any C compiler, I think it is
>>>> best if we default to the less demanding version of the implementation
>>>> for unknown compilers.
>>> While building Xen out of box is nice goal to have, this is likely be very
>>> hard to reach out because Xen is using a lot of GCCism. It mostly work with
>>> Clang because they have adopted some of them.
>>>
>>> I would be happy to revert the condition, but then AFAICT there are no pretty
>>> way to now that we are using GCC. While the define __GNUC__ is meant to tell
>>> you this is compiled with GCC, clang is also defining it.
>>
>> That's horrible, I didn't know about that!
>>
>>
>>> So the condition would have to be
>>>
>>> #if !defined(__clang__) && defined(__GNUC__)
>>
>> :-(
>>
>>
>>> But then if clang is already defining __GNUC__, what actually prevents any
>>> other to do it?
>>>
>>> I have yet to see anyone wanted to build Xen with another compiler other than
>>> clang and GCC. So I will leave this patch as is. Feel free to suggest a
>>> different approach if you are not happy with this.
>>
>> Is there a __REALLY_REALLY_GUNC__ variable? I guess not, so I don't have
>> a better suggestion. This problem is quite annoying (not your fault of
>> course) I wonder how other projects deal with it. There must be a
>> "clean" way to distinguish gcc from others?
>>
>> For now, I am OK with this patch as is because I wouldn't know what else
>> to suggest, and I agree that !defined(__clang__) && defined(__GNUC__) is
>> bad.
> 
> and you can add:
> 
> Acked-by: Stefano Stabellini <sstabellini@kernel.org>

Thank you. I have also updated the commit message to reflect the discussion:


     xen/arm: fix get_cpu_info() when built with clang

     Clang understands the GCCism in use here, but still complains that sp is
     unitialised. In such cases, resort to the older versions of this code,
     which directly read sp into the temporary variable.

     Note that GCCism is still kept in default because other compilers (e.g.
     clang) may also define __GNUC__, so AFAIK there are no proper way to
     detect properly GCC.

     This means that in the event Xen is ported to a new compiler, the code
     will need to be updated. But that likely not going to be the only place
     where Xen will need to be adapted...

     This is based on the x86 counterpart.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel