Tweak data abort handler to try and avoid recusrive aborts confusing AMBControl

Detail:
  s/VMSAv6 - The code to detect aborting MVA ops now only runs if the aborting instruction wasn't located in application space.
  This is a workaround for an issue where:
  (a) The aborting instruction is in application space
  (b) The aborting instruction is attempting to access memory located in the same page as itself
  (c) That page is not mapped in (despite the fact that code is being executed from it)
  Originally attempting to load the aborting the instruction would have triggered another abort, causing AMBControl to map in the page and resume the first abort handler. The first abort handler would then have determined that it wasn't an MVA op and called AMBControl, only to be told by AMBControl that it wasn't a lazy fixup abort (even though it really was), thus triggering the abort environment handler.
  By ignoring instructions located in application space the second abort is avoided, allowing AMBControl to correctly process the abort.
Admin:
  Tested on rev A2 BB-xM.
  Fixes issue with DPScan crashing - http://www.freelists.org/post/davidpilling/DPScan-ARMini-crash
  Still need to determine how the ICache is able to become so out of sync with the DCache & page tables.


Version 5.35, 4.79.2.98.2.40. Tagged as 'Kernel-5_35-4_79_2_98_2_40'

VersionASM

@@ -13,11 +13,11 @@
                         GBLS    Module_ComponentPath
 Module_MajorVersion     SETS    "5.35"
 Module_Version          SETA    535
-Module_MinorVersion     SETS    "4.79.2.98.2.39"
-Module_Date             SETS    "09 Jun 2011"
-Module_ApplicationDate  SETS    "09-Jun-11"
+Module_MinorVersion     SETS    "4.79.2.98.2.40"
+Module_Date             SETS    "24 Jul 2011"
+Module_ApplicationDate  SETS    "24-Jul-11"
 Module_ComponentName    SETS    "Kernel"
 Module_ComponentPath    SETS    "castle/RiscOS/Sources/Kernel"
-Module_FullVersion      SETS    "5.35 (4.79.2.98.2.39)"
-Module_HelpVersion      SETS    "5.35 (09 Jun 2011) 4.79.2.98.2.39"
+Module_FullVersion      SETS    "5.35 (4.79.2.98.2.40)"
+Module_HelpVersion      SETS    "5.35 (24 Jul 2011) 4.79.2.98.2.40"
                         END

VersionNum

@@ -5,19 +5,19 @@
  *
  */
 #define Module_MajorVersion_CMHG        5.35
-#define Module_MinorVersion_CMHG        4.79.2.98.2.39
-#define Module_Date_CMHG                09 Jun 2011
+#define Module_MinorVersion_CMHG        4.79.2.98.2.40
+#define Module_Date_CMHG                24 Jul 2011
 
 #define Module_MajorVersion             "5.35"
 #define Module_Version                  535
-#define Module_MinorVersion             "4.79.2.98.2.39"
-#define Module_Date                     "09 Jun 2011"
+#define Module_MinorVersion             "4.79.2.98.2.40"
+#define Module_Date                     "24 Jul 2011"
 
-#define Module_ApplicationDate          "09-Jun-11"
+#define Module_ApplicationDate          "24-Jul-11"
 
 #define Module_ComponentName            "Kernel"
 #define Module_ComponentPath            "castle/RiscOS/Sources/Kernel"
 
-#define Module_FullVersion              "5.35 (4.79.2.98.2.39)"
-#define Module_HelpVersion              "5.35 (09 Jun 2011) 4.79.2.98.2.39"
+#define Module_FullVersion              "5.35 (4.79.2.98.2.40)"
+#define Module_HelpVersion              "5.35 (24 Jul 2011) 4.79.2.98.2.40"
 #define Module_LibraryVersionInfo       "5:35"

s/VMSAv6

@@ -476,8 +476,17 @@ DAbPreVeneer    ROUT
         ; MVA TLB ops have the form coproc=p15, CRn=c8, opc1=0, opc2=1
         ; Note that some non-MVA ops also follow the above rules - at the moment we make no attempt to filter those false-positives out
         ; This code is also written from the perspective of running on an ARMv7 CPU - behaviour under ARMv6 hasn't been checked!
-        ; Also, as wrong as it seems, attempting to load the aborting instruction could trigger an abort (something wrong with the prefetch handler?)
+
+        ; Also, as wrong as it seems, attempting to load the aborting instruction could trigger an abort (something wrong with the prefetch handler? or cache flushes not being done properly?)
         ; So this code must protect DFAR, DFSR, spsr_abort, and lr_abort from being clobbered
+
+        ; We also need to be careful about how AMBControl will react to the abort:
+        ; If DFAR and lr_abort both point to the same page, when we try loading the instruction (and it triggers an abort), AMBControl will map in the page
+        ; So when control returns to us (and we determine that it wasn't an MVA op) AMBControl will be called again (for DFAR), see that the page is mapped in, and claim that it's a real abort instead of the lazy fixup that it really is
+        ; (The workaround for that issue probably makes the DFAR, DFSR, spsr_abort, lr_abort saving irrelevant, but it's better to be safe than sorry)
+
+        CMP     lr, #AplWorkMaxSize             ; Assume that MVA ops won't come from application space (cheap workaround for above-mentioned AMBControl issue)
+        BLO     %FT10
         MRS     r1, SPSR
         TST     r1, #T32_bit
         BNE     %FT10                           ; We don't cope with Thumb ATM. Should really check for Jazelle too!