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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 18.01.19 at 11:48, <julien.grall@arm.com> wrote:
> On 18/01/2019 09:54, Jan Beulich wrote:
>>>>> On 18.01.19 at 02:24, <sstabellini@kernel.org> wrote:
>>> On Thu, 17 Jan 2019, Jan Beulich wrote:
>>>>>>> On 17.01.19 at 01:37, <sstabellini@kernel.org> wrote:
>>>>> On Wed, 16 Jan 2019, Jan Beulich wrote:
>> Stop. No. We very much can prove they are - _end points at
>> one past the last element of _start[]. It is the compiler which
>> can't prove the opposite, and hence it can't leverage
>> undefined behavior for optimization purposes.
> 
> You keep saying the compiler can't leverage it for optimization purpose, 
> however 
> there are confirmations that GCC may actually leverage it (e.g [1]). You 
> actually need to trick the compiler to avoid the optimization (e.g 
> RELOC_HIDE).
> 
> So obviously, this is not only a MISRA "problem" as you state here and 
> below.
> 
> I believe Stefano, Stewart and I provided plenty of documentation/thread to 
> support our positions. Can you provide us documentation/thread showing the 
> compiler will not try to leverage that case?
> 
> Cheers,
> 
> [1] 
> https://kristerw.blogspot.com/2016/12/pointer-comparison-invalid-optimization.html?m=1

Btw., the __start[] / __end[] example given there does not match
up with what I see. Only symbols defined in the same CU as where
the comparison sits get "optimized" this way. Externs as well as
weak symbols defined locally don't get dealt with like this. And how
could they? Nothing tells the compiler that two distinct symbols
refer to two distinct objects. It is easy to create objects with
multiple names, not only in assembly but also in C (using the "alias"
attribute).

Jan



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