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

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

>>> On 18.01.19 at 16:22, <julien.grall@arm.com> wrote:
> On 18/01/2019 11:09, Jan Beulich wrote:
>>>>> 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).
>> 
>> Correct - that's the case I'm referring to when saying it can't leverage
>> undefined behavior optimizations anymore. Without the hiding of
>> course it can.
> 
> But this trick is GCC specific, right? So we would need to have one trick for 
> each compiler we support.

I don't think so; I can't see it to be legitimate for a compiler to derive
anything from what's inside an asm(). It may not be spelled out that
way, but it is my understanding that all knowledge the compiler is
allowed to derive from an asm() is encoded in the in/out/clobber etc
operands of the asm(); the first operand - the string literal - is
supposed to be opaque as far as the asm()'s operation goes.

Jan



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