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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.02.19 at 16:41, <ian.jackson@xxxxxxxxxx> wrote:
> 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'.

If you want to be "prepared" for them taking apart asm()-s, how
would you expect them to never "look through" casts?

>  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.

Hmm, that's certainly an interesting approach, and requires
care only when introducing a new pair of symbols of this kind.
But of course the macro you suggest to carry out the
comparison will have the same weakness as any open coded
cast to a suitable integer type. But there are benefits:
- it marks problem sites clearly (one of Stefano's goals),
- it isolates future changes to how exactly the comparisons
  are to be done to the comparison macro(s)
- it doesn't undermine type safety of the main (start-of-
  whatever) symbols (one of my goals),
- it allows the end-of-whatever symbols to also be handed to
  functions in a type-safe manner (we could even have
  per-instance structure flavors, such that unrelated "end"
  symbols can't be mixed up; for example the type could
  simply be a structure wrapping a field of the original base
  type).

Jan



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