RISC OS's abort handler / lazy page mapping

Where’s the source code for this? I’ve looked through the source, but can’t find either.

When an Abort occurs in my abort handler due to the page not being mapped (The L2PT entry is 0), the instruction is retried in User mode, not Abort mode. I want to see what RISC OS does when it resumes the aborting instruction.

Should be working, took quick toilet break. Try …kernel.AMB or something like that.

kernel.s.AMBControl was the first place I looked, I’ll have a more detailed look at the files

I had a quick look on my phone (not great for reading source) while on break. Perhaps the best idea would be to examine the HAL to find the abort handler, then work through the code from there?
If you don’t know, Sh-Ctrl-H in Zap opens a window with a list of things that look like function names to it – it is often polluted with the %10 style of label, but it’s a lot simpler than guesswork.
Or, you know, F4. ;-)

The data & prefetch abort handlers are DAbPreVeneer and PAbPreVeneer in s.VMSAv6/s.ARM600 (depending on MMU model). These then call through to AMB_LazyFixUp in the AMBControl code in order to deal with lazy task swapping. If AMBControl says that it’s handled the abort then DAbPreVener/PAbPreVeneer just resumes execution using a MOVS PC,LR-type instruction, otherwise execution will flow through to the rest of the abort handlers (e.g. whatever handler was installed via OS_ClaimProcessorVector – or at least I’m fairly certain those are lower priority than the pre-veneers)

Beware that there is some dark magic in the abort handlers, e.g. code to deal with aborting cache maintenance ops on ARMv7, and AMBControl itself sometimes deliberately triggers aborts as a cheap-and-cheerful way of forcing pages to be mapped in (If memory serves, this only happens when it thinks the abort is a non-lazy abort – so it maps everything in to make sure the error handler can execute correctly, or something like that).

I’m only seeing the problem on RO5.21 on the Pi, RO5.20 on SA doesn’t look like it implements lazy mapping.

The sequence of events is:

1. An STM in User mode that will wrap onto an unmapped page triggers an access permission
2. My Abort handler decodes the instruction and starts proxying the write via a loop using STR
3. When the STR hits the first word of the unmapped page, another Abort is triggered
4. My handler seeing that it’s already dealing with an Abort passes the abort on
5. RISC OS’s Abort handler does its thing and maps the page
6. I’m guessing RISC OS then retries the instruction, the only problem being the CPU is now in User mode, not Abort

It’s step 5/6 that I want to check

RO5.20 on SA doesn’t look like it implements lazy mapping.

Depends on CPU revision – prior to revision T, StrongARM CPUs had a bug which meant lazy task swapping wasn’t reliable.

PAbPreVeneer doesn’t do anything out of the ordinary. In hindsight, an Abort occurring in an Abort handler is going to cause all kinds of issues, so I’ll probably work around it by effectively turning the lazy page mapping off. I’ll force the whole WimpSlot to be mapped when it’s created by accessing every page.

With the current sequence of events, I’d expect the Abort SPSR to be corrupted when the lazy page Abort triggers and for my Abort handler to return incorrectly in Abort mode (due to the corrupt SPSR). I’m not sure how the OS abort handler is returning in User mode, unless the ARM is not setting SPSR when an Abort occurs when in Abort mode.

Thanks for your help.

Depends on CPU revision – prior to revision T, StrongARM CPUs had a bug which meant lazy task swapping wasn’t reliable.

I’m checking by doing a *WimpSlot and then looking at L2PT to see if the pages are mapped.

In hindsight, an Abort occurring in an Abort handler is going to cause all kinds of issues, so I’ll probably work around it by effectively turning the lazy page mapping off. I’ll force the whole WimpSlot to be mapped when it’s created by accessing every page.

There’s also the OS_AMBControl SWI which can be used to turn lazy swapping on/off at a global level (but it is marked for internal use only, so may change unexpectedly between OS versions)

Thanks for your help.

No problem!

Accessing every page after calling Wimp_SlotSize has resolved the problem.