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

[Stewart Hildebrand <Stewart.Hildebrand@xxxxxxxxxxxxxxx>]

On Monday, January 14, 2019 10:53 AM, Jan Beulich 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).
> 
> Jan

In the following declaration:
extern char _start[], _end[];
it's still a valid interpretation that _start and _end point to different 
objects. In fact, I think is already making this assumption, given that GCC 7.3 
will emit the following warning if "extern" is removed: "warning: array ‘_end’ 
assumed to have one element"

Who's to say that GCC someday won't become smart enough to sniff out all the 
inline assembly and pointer-type casts and still draw the conclusion that they 
point to separate objects? What if GCC someday will make these decisions based 
on some sort of link-time optimization, like using an intermediary or iterative 
symbol/linker map of sorts? It seems that using pointer types is at best a 
cat-and-mouse chase. GCC has too many unregulated moving pieces - it's a much 
stronger argument just to adhere to the standard. My vote still goes to 
uintptr_t.

Also, the above text only concerns equality comparisons. What about 
greater/less/neq comparisons, arithmetic, and dereferencing?

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