>Is there any reason why the bug can't be detected in software?  If the 
>manifestation is just that you take a page fault sometimes when you shouldn't 
>do then your data abort handler can examine the faulting instruction, see if 
>it's an LDM, and take the appropriate evasive action (like emulating it or 
>executing it out of line) if so.  I admit though that I haven't looked at the 
>problem in detail so maybe this isn't possible.
> 
>Losing `LDM' is going to be quite a big hit - you certainly don't want it to 
>default to on for the sake of avoiding an occasional bug on some steppings of 
>one CPU.

The question is, is losing it in the circumstances where it can cause
trouble going to be a big hit?

for instance, the one bug which i'm familiar with is:

	ldmib rN, {reg list including rN}

where access to the register storage memory (i.e. the memory being
loaded) causes a fault after at least one (but obviously not all)
registers are loaded.  (Note that it has nothing to do with the
position of the ldmib in virtual space, it's the location of the data
being accessed.)  That is, the registers being loaded happen to cross
a page boundary.

That's a pretty rare case, as far as I can tell.

I can get GCC to generate a possibly-failing instruction with the
(constructed) code sequence:

	struct foo {
	        int x;
	        struct bar {
	                struct foo *next;
	                int a;
	        } y;
	};

	fn(f)
		register struct foo *f;
	{
	        f->y = f->y.next->y;
	}

but if i tweak that in the minor ways, the possibly-losing instruction
is no longer generated.


I don't think that a flag for "don't generate that instruction" for
_that particular instruction_ would either be painful to implement or
expensive in terms of code.  If you wanted, you could 'pre-fault' the
pages by trying to read the first and last bits of register storage
memory, or something, but in that case the workaround may be more
annoying than simply avoiding the case.

However, I don't know what the other bugs are, so can't comment on how
hard they'd be to work around.



cgd
(Not speaking for Digital, etc.)