Determining if an Abort is due to lazy page mapping
Jon Abbott (1421) 2651 posts |
What method should I use to determine if an Abort has been triggered by lazy page mapping? I presume I’m looking for Translation and/or Domain faults in FSR? As Alignment faults are the highest priority, should I first check L2PT to ensure the page FAR points too exists, prior handling the misalignment? Or am I better off triggering a page fault whilst handling the misalignment and passing it on, on re-entry to the Abort handler? Finally, do I need to handle Prefetch Aborts differently, as I’m not sure if these update FSR/FAR. |
Jeffrey Lee (213) 6048 posts |
It’ll be a translation fault – the page table entries for the mapped out pages are all set to 0.
I’d recommend making your abort handler re-entrant and passing on the translation fault. If you encounter code which deliberately triggers aborts (e.g. as part of a copy protection routine) then this may cause some issues (the aligned access your abort handler generates will abort, the error handler will be invoked, and by looking at the register dump the game will be able to spot that the code is being debugged/hacked). But I’d be surprised if you found a game with copy protection which was that devious.
On ARMv6+ there are two sets of fault registers (DFSR/DFAR for data aborts, IFSR/IFAR for prefetch aborts). DFSR/DFAR are the same register numbers as the old FSR/FAR. On ARMv5 and below it looks like prefetch aborts update the FSR but not the FAR. |