[U-Boot] [PATCH] 8313erdb: Set guarded bit on BAT that covers the end of the address space.

[Scott Wood <scottwood@freescale.com>]

Mike Frysinger wrote:
>> No.  The dereference was on a not-taken side of a conditional branch.
> 
> you mean in the shadow ?  so something like:
> p = NULL;
> if (p != NULL) {
> 	/* this is the shadow region */
> }

Yes.

>>> if C code is doing ptr checks, the compiler should make sure that
>>> pointer is not dereferenced at all if the hardware cannot suffer the
>>> consequences, even speculatively.
>> There is no reasonable way for the compiler to prevent such speculative
>> accesses.  Non-memory-like mappings must have the guarded bit set.  That
>> is what the bit is there for.
> 
> if the hardware doesnt have a way of preventing it, then the compiler must nop 
> bad accesses that are unknown.

The hardware *does* have a way of preventing it.  It's the guarded bit. :-)

I don't know of any amount of "nop" instructions that would be 
architecturally guaranteed to avoid this -- they're no-ops, not syncs 
(despite how some other architectures use them).  They can be discarded 
as fast as the chip can decode them.

Adding an isync instruction should avoid it, but that's a heavy 
performance penalty.  Why pay it for all accesses rather than just those 
which are not memory-like (and can be flagged as such in the TLB)?

> i'm not sure your example proves your position.  if you have a region that 
> cannot stand speculative access, how do you handle bad pointer checking if the 
> compiler may generate code that'll speculatively hit it at any time ?

The compiler is not speculatively doing anything.  It is the CPU -- and 
the guarded bit tells it to not do that.

-Scott