> Tony Houghton wrote:
> > I don't know the exact details of the bug, and the superficial details
> > I've seen here have two conflicting views. Most people seem to think
> > that the problem is caused by the LDM instruction itself lying on a page
> > boundary, but at least one posting says it's if the data it's loading is
> > on a page boundary. If the latter, it rules out one possible solution ie
> > replacing LDM with LDM followed by a noop and getting the linker to swap
> > them if necessary. That wouldn't be popular with the porting team
> > anyway, requiring the compiler and linker to be patched and most
> > binaries to be recompiled.
> 
> It's if the instruction is on the end of a page, not the data.

I see. Then the problem should be easy solved, by simply never putting
the instruction on the end of a page. One could always put a NOP
on the end of pages.

I really would like to have a more accurate descriptioin of the bug,
so that a workaround my be fixed, as long as the kernel team don't
fix it.

Please protest if my understanding of the bug is wrong:

It only concerns the LDM^ instruction, not the LDM instruction?
If so, don't use the LDM^ instruction, but instead LDM, and get
the CPSR by a separate instruction. (I am not entirely clear heare)

The paging fault generated by the PC after loading the instruction,
messes up the instruction somehow? What exactly is lost?

According to my ARM manual, if the LDM^ instruction uses a stack
register, its changed value is not written back to the register 
before the instruction is completed. If a fault happens,
it is not written back at all, making it possible for the
virtual memory system to just execute the instruction again
after the pagefault is fixed. Where do the bug fit into this
picture?

R14 gets thrashed? How? When? Why?

Kim0