[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |