Re: [Xen-devel] [PATCH v2 3/3] xen: hook up UBSAN with CONFIG_UBSAN

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Oct 09, 2017 at 03:38:55PM +0100, Andrew Cooper wrote:
> On 09/10/17 15:36, Jan Beulich wrote:
> >>>> On 09.10.17 at 16:11, <wei.liu2@xxxxxxxxxx> wrote:
> >> --- a/xen/common/ubsan/ubsan.c
> >> +++ b/xen/common/ubsan/ubsan.c
> >> @@ -10,13 +10,18 @@
> >>   *
> >>   */
> >>  
> >> -#include <linux/bitops.h>
> >> -#include <linux/bug.h>
> >> -#include <linux/ctype.h>
> >> -#include <linux/init.h>
> >> -#include <linux/kernel.h>
> >> -#include <linux/types.h>
> >> -#include <linux/sched.h>
> >> +#include <xen/spinlock.h>
> >> +#include <xen/percpu.h>
> >> +
> >> +#define __noreturn    noreturn
> >> +#define pr_err(...) printk(XENLOG_ERR __VA_ARGS__)
> >> +struct xen_ubsan { int in_ubsan; };
> >> +static DEFINE_PER_CPU(struct xen_ubsan[1], in_ubsan);
> >> +#undef current
> >> +#define current this_cpu(in_ubsan)
> >> +#define dump_stack dump_execution_state
> >> +#define u64 long long unsigned int
> >> +#define s64 long long int
> > Wasn't it agreed to make these uint64_t and int64_t?
> 

No, not yet.

> Sadly that doesn't work, because of the explicit casts used in the
> sprintf().
> 
> Depending on how much we tolerate modifying the Linux code, these can be
> removed if we change to using appropriate PRIx64 formatters instead. 
> However, I would prefer to avoid changing the Linux code if possible.

+1 for this.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel