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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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. As soon as the
actual comparison is in place, we're fine code-wise. Whether that's
also fine MISRA-wise is a different thing, but as said before I
question the validity of demanding C standard compliance of
constructs originating from other than C (and perhaps not even
expressible in standard compliant C).

Jan



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