In message <19980505.192226.95@impala.demon.co.uk> I wrote:

> In message <354CC32E.3DF74E1B@causality.com> you wrote:
> 
> > Adam Gundy wrote:
> > 
> > > The reason I've found this is that I've added some code to the
> > > prefetch abort handler to try and fix the StrongARM LDM bug -
> > > unfortunately it ends up with the same panic...
> > 
> > It's unfixable. I've just clarified that in the fault taken, apparently
> > R14 can get trashed so there's not always a way to get bck. Bummer.
> > Approaching Acorn/Simtec is probably the best bet!
> 
> The solution then is not to allow the fault to occur (which is what
> my fix attempts to do):

<snip>

> the number of pages locked in memory isn't too bad; my gcc 2.8.0 has about
> 6 LDMs (this number is going to change now that I've seen the DEC errata -
> I'll have to look for LDRs as well as LDMs, but to counter that I can
> ignore both if they don't change the PC). I can see that when running
> X a fair number of pages will need to be wired :-(
> 
> PS for a complete solution the data abort handler will have to do the
>    same checks if the abort is from an executable section of memory
>    (in case a constant is read from a page with an LDM/LDR).

If anyone is interested I have a small program which scans an a.out
binary looking for unsafe instructions (LDM/LDR into PC) - surprisingly
my cc1plus binary has only one problem (which is worrying because it
falls over all the time when swapping).

Xarm-33 appears to have 19 unsafe instructions, which probably explains
why it lasts about half an hour on my machine ;-)

mail me if you want a copy (5.5k compressed binary / 6.5k compressed
source).

Seeya,
 Adam.
-- 
As the year 2000 approaches, the carefully planned Millenium 'bug'
begins to manifest itself in the computing job market...
Real programmers don't comment their code. If it was hard to write, it
should be harder to modify. These are all my own opinions.