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

[Mike Frysinger <vapier@gentoo.org>]

On Tuesday 17 March 2009 13:52:27 Scott Wood wrote:
> On Tue, Mar 17, 2009 at 01:47:04PM -0400, Mike Frysinger wrote:
> > On Tuesday 17 March 2009 13:09:31 Scott Wood wrote:
> > > This board currently sets DBAT6 to cover all of the final 256MiB of
> > > address space; however, not all of this space is covered by a device. 
> > > In particular, flash sits at 0xfe000000-0xfe7fffff, and nothing is
> > > mapped at the far end of the address space.
> > >
> > > In zlib, there is a loop that references p[-1] if p is non-NULL.  Under
> > > some circumstances, this leads to the CPU speculatively loading from
> > > 0xfffffff8 if p is NULL.  This leads to a machine check.
> >
> > isnt that a compiler generating bad code then ?
>
> 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 */
}

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

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 ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090317/cf151424/attachment.pgp