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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.19 at 17:26, <Stewart.Hildebrand@xxxxxxxxxxxxxxx> wrote:
> 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"

I'm afraid you're mixing up things. Removing the "extern" converts the
construct from a declaration to a (latent, determined once the entire
CU has been parsed) definition. The expansion to one element that
the compiler does is specifically to avoid pointers to compare equal
despite pointing at different objects (if there was no element, the
next sequential object in memory would have the same address, and
hence pointers would compare equal).

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

Looking through casts between pointer types is already happening.
Inspecting the actual text of an asm() is, otoh, something that
should never happen, as it would be extremely error prone.

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

That's why hiding it through an asm() is imo best, because the asm()
will be retained in the internal representation, and hence remain
immune from such optimizations.

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

Different subject.

Jan


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