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

[Julien Grall <julien.grall@xxxxxxx>]

Hi Jan,

On 18/01/2019 11:09, Jan Beulich wrote:
> > > > On 18.01.19 at 11:48, <julien.grall@xxxxxxx> wrote:
> > On 18/01/2019 09:54, Jan Beulich wrote:
> > > > > > On 18.01.19 at 02:24, <sstabellini@xxxxxxxxxx> wrote:
> > > > On Thu, 17 Jan 2019, Jan Beulich wrote:
> > > > > > > > On 17.01.19 at 01:37, <sstabellini@xxxxxxxxxx> 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. Note that the solution originally suggested by Stefano 
has the same issue (i.e return unsigned long).
Cheers,

--
Julien Grall

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