[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Jan Beulich writes ("Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL"):
> As per my earlier reply, I've yet to see proof of a "code-breaking
> optimization" that actually matches our case(s).

I have personally experienced a program being miscompiled because of
the mistaken belief by the compiler that _start and _end were
different objects.  I have read haven't read back the whole history of
this but this is definitely a real bug.

I agree with George that this is a compiler bug.  However, this bug is
not going to be fixed because the compiler community's behaviour is as
unreasonable as George paints :-(.

Our only option is some kind of bodge.

I don't believe in the asm fragment bodge because we don't have a
promise anywhere from the compiler authors that the asm hides pointer
provenance.  I am not aware of any C technique which can be reliably
used to obscure pointer provenance and prevent this kind of
misoptimisation.  Linux is skating on thin ice here.

That leaves:

(i) define indirection variables eg end_ in an assembly language file.
(ii) convert to uintptr_t before comparing

(i) is IMO wholly safe but it is a bit ugly and slightly less
performant.

I think (ii) is fairly safe.  I doubt that we will find (ii) broken.
In particular, because there is little motivation for compiler authors
to try to `optimise it'.  The difficulty with it providing automatic
way of detecting when we accidentallyf fail to cast.  I suggest the
following:

 extern const struct wombat _wombats_start[];
 extern const struct abstract_symbol _wombats_end[];

and providing a macro which compares any pointer with a struct
abstract_symbol* by converting the latter to a uintptr_t.  Direct
comparisons of _wombats_start with _wombats_end will result in a
compilation error due to type mismatch.

Ian.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.