[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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@xxxxxxx>
---
   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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.