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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 17:28, <julien.grall@xxxxxxx> wrote:
> 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.

You're inverting what was said before: Of course the compiler
can#t be sure the addresses are not equal. But from the mere
language structure it knows that __start[] and __end[] are
two different objects.

> 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.

Of course.

> 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.

Of course there is: There's no connection to the original object(s)
anymore. Same with

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

void test(const struct my_struct *);

void foo(int i) {
        test(i ? __start : __end);
}

Wherever test() is defined, the compiler can't make assumptions
anymore (unless of course it gets to see the definition, e.g. via
whole program optimization). But if the function's implementation
lives in a different binary, the compiler just can't make any
assumptions anymore.

Jan


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