Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Julien Grall <julien.grall@xxxxxxx>]

Hi Jan,

On 14/01/2019 15:52, Jan Beulich wrote:
> > > > On 14.01.19 at 16:41, <julien.grall@xxxxxxx> wrote:
> > Hi Jan,
> >
> > On 14/01/2019 10:11, Jan Beulich wrote:
> > > > > > On 11.01.19 at 19:04, <sstabellini@xxxxxxxxxx> wrote:
> > > > On Fri, 11 Jan 2019, Jan Beulich wrote:
> > > > > > > > On 11.01.19 at 03:14, <sstabellini@xxxxxxxxxx> wrote:
> > > > > > Hi Juergen, Jan,
> > > > > >
> > > > > > I spoke with Julien: we are both convinced that the unsigned long
> > > > > > solution is best. But Julien also did some research and he thinks that
> > > > > > Jan's version (returning pointer type) not only does not help with
> > > > > > MISRA-C, but also doesn't solve the potential GCC problem either. A
> > > > > > description of the GCC issue is available here:
> > https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization
> > .h
> > > > tml?m=1
> > > > > I've read through it, and besides not agreeing with some of the
> > > > > author's arguments I wasn't able to spot where it tells me why/how
> > > > > the suggested approach doesn't solve the problem.
> > > > >
> > > > > > (Also keep in mind that Linux uses the unsigned long solution to solve
> > > > > > the GCC issue, deviating from it doesn't seem wise.)
> > > > > Which specific gcc issue (that is not solved by retaining type)?
> > > > I am hoping Julien and his team will be able to provide the more
> > > > decisive information next week for us to make a decision, but it looks
> > > > like the issue is not clear-cut and people on the GCC list disagree on
> > > > how it should be handled.
> > > >
> > > >
> > > > The C standard says that "Two pointers compare equal if and only if both
> > > > are null pointers, both are pointers to the same object (including a
> > > > pointer to an object and a subobject at its beginning) or function, both
> > > > are pointers to one past the last element of the same array object, or
> > > > one is a pointer to one past the end of one array object and the other
> > > > is a pointer to the start of a different array object that happens to
> > > > immediately follow the first array object in the address space."
> > > >
> > > > In short, the compiler is free to return false in a pointer comparison
> > > > if it believes that the pointers point to different non-consecutive
> > > > object.
> > > And it is this "it believes" which we undermine with the construct:
> > > As long as the compiler can't prove two pointers point to different
> > > objects, it can't eliminate the actual comparison.
> > May I ask where does this come from? A compiler could technically be free to
> > assume the inverse. I.e as long as it can't prove two pointers point to
> > different objects, it can rely on the undefined behavior to optimize it.
> No. As long as there's a chance that both pointers point to the same
> object, it can't do bad things, because _if_ they do, the result of the
> comparison has to be correct (as per the text still quoted above).
In the following example (taken from [1]):

extern struct my_struct __start[];
extern struct my_struct __end[];

void foo(void)
{
    for (struct my_struct *x = __start; x != __end; x++)
        do_something(x);
}

The compiler can't be sure that __start and __end are not equal. Yet it may 
decide they are always different and optimize it to an infinite loop. So surely, 
the compiler can do bad things with even simple code.
I am struggling to understand how using "asm volatile" and still returning a 
pointer would help here. If the compiler managed to infer that __start and __end 
are always different, then there are no reason for this to not happen with the 
new construct.
I have been told that -fno-strict-aliasing may help us for pointer arithmetic. 
But I am still haven't find any evidence yet.
Cheers,

[1] 
https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization.html?m=1

--
Julien Grall

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