From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Tue, 17 Mar 2009 13:18:13 -0500 Subject: [U-Boot] [PATCH] 8313erdb: Set guarded bit on BAT that covers the end of the address space. In-Reply-To: <200903171407.29266.vapier@gentoo.org> References: <20090317170931.GA14779@ld0162-tx32.am.freescale.net> <200903171347.06090.vapier@gentoo.org> <20090317175226.GD12636@ld0162-tx32.am.freescale.net> <200903171407.29266.vapier@gentoo.org> Message-ID: <49BFE965.40904@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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