dabort.txt

基于ARM920T内核的S3C2410下的databort（数据异常模式）程序

    LDR Rd,[Rn,-Rn,<shift>]!     STR Rd,[Rn,-Rn,<shift>]!

  The issue here is the combination of a number of facts:

  a) A data abort handler can always recover from such instructions, but
     cannot always use the standard algorithms for doing so. In particular,
     with the Base Updated Abort Model, such an instruction must be treated
     as a special case.

  b) The architectural position of such instructions is somewhat dubious:
     the ARM ARM says that both these instructions and the corresponding
     post-indexed ones are "UNPREDICTABLE", but all ARM datasheets just say
     this about the post-indexed versions.


Parameters of the OS-specific Handler Call
------------------------------------------

The parameters passed to the OS-specific handler are a single obligatory
"error code" parameter followed by a number of optional parameters. All
parameters are word-sized (or smaller values which are passed as words). The
exact mechanism by which parameters are passed is determined by the
procedure calling standard being used.

The error code parameter is zero to indicate that no error occurred, and is
set to an error number otherwise. It is always the first parameter to the
OS-specific handler. See "Errors" below for details of the possible errors.

The optional parameters are the CPSR value at the time the instruction
aborted, the address of the aborting instruction and the address of the data
to be transferred by the aborting instruction. These are requested
respectively by the "PassSPSR", "PassInstrAddr", "PassRegDumpAddr" and
"PassXferAddr" options listed under "Standard Assembly-time Options" above.
The requested optional parameters (if any) are passed as the 2nd and
subsequent parameters to the OS-specific handler, in the appropriate
sub-order of:

  SPSR, instruction address, register dump address, transfer address

All parameters as normal ARM 32-bit words, and may in general be treated as
being of any type compatible with such words under the chosen procedure
calling standard and/or any relevant language bindings. (The error code
parameter is a slight exception to this: it should additionally be treated
as a signed value.)


Return Value from the OS-specific Handler Call
----------------------------------------------

If it returns, the OS-specific handler must return a single value, which
should be one of the following. To avoid the inclusion of too much unwanted
code, each type of return value is only permitted if the corresponding
"ReturnXXXX" assembly-time option is set.

* 0x0 to request normal data abort recovery actions (normally instruction
  retry). (Enabled by the "ReturnNormal" assembly-time option.)

  This is only a legitimate return value if no error was reported on entry
  to the OS-specific handler.

* 0x4 to request that the data abort veneer should unwind all its normal
  effects (e.g. on the abort mode stack) and "return" in such a way as to
  fake an entry to the undefined instruction trap. (Enabled by the
  "ReturnUndef" assembly-time option.)

  The "ReturnUndef" assembly-time option specifies precisely where the faked
  undefined instruction trap is to be entered. This may be specified as a
  hexadecimal number starting with the characters "0x": such a definition
  will be used as an absolute address. If "ReturnUndef" is anything else, it
  will be treated as the name of a symbol which should be IMPORTed and used
  as the address of the trap handler.

  To fake an entry to the standard ARM undefined instruction trap, set
  "ReturnUndef" to "0x00000004". To fake one to the "high vectors" undefined
  instruction trap on an ARM with the appropriate facility, set
  "ReturnUndef" to "0xFFFF0004". (It is also possible to set "ReturnUndef"
  to other values, to cause a non-standard "undefined instruction trap"
  entry: this can be useful e.g. to avoid the problem described in the
  warning below.)

  The register values on entry to the undefined instruction trap are the
  same as those on the original entry to the data abort trap, except that
  (a) abort-model-specific base register restoration has been done as
  necessary; (b) R14_undef, SPSR_undef and the CPSR will be set to what they
  would have been had the aborting instruction actually been an undefined
  instruction.

  This is a legitimate return value regardless of the error code on entry to
  the undefined instruction handler.

  (WARNING: It should be noted that some standard undefined instruction
  handling code does not currently correctly deal with LDMs and STMs that
  manage somehow to enter the undefined instruction trap. This includes the
  undefined instruction handlers in the FPE and the FPA Support Code, with
  the result that use of this return value is currently incompatible with
  any floating point option other than the floating point library.)

* 0x10 to request that the data abort veneer should unwind all its normal
  effects (e.g. on the abort mode stack) and "return" in such a way as to
  fake an entry to a second data abort handler. (Enabled by the
  "ReturnToNext" assembly-time option, which also specifies what the
  address of that second handler is.)

  The register values on entry to the second data abort handler are the same
  as those on the original entry to the data abort trap, except that
  abort-model-specific base register restoration has been done as necessary.

  This is only a legitimate return value if no error was reported on entry
  to the OS-specific handler.

* A non-zero address to request that the data abort veneer should unwind all
  its normal effects (e.g. pop any values it pushed on to the abort mode
  stack), then transfer control to that address. (Enabled by the
  "ReturnAddress" assembly-time option.)

  When control arrives at that address, the processor will be in the same
  mode as it was when the OS-specific handler was called (i.e. as determined
  by the "HandlerCallMode" assembly-time option described under "Standard
  Assembly-time Options" above). Register values will be the same as they
  were on the original entry to the data abort trap, except that
  (a) abort-model-specific base register restoration has been done as
  necessary; (b) for banked registers, the value will have been shifted to
  the new mode's version of the register.

  This is a legitimate return value regardless of the error code on entry to
  the undefined instruction handler.

Any returned value which is not one of the specific return values listed
above will be treated as the "return an address" option, as will any
specific return value whose corresponding "ReturnXXXX" option is not set. If
the "ReturnAddress" assembly-time option is not set, anything treated as the
"return an address" option will instead be treated as an erroneous and
invalid request by the OS-specific handler.

The OS-specific handler may also fail to return, but must in that case take
responsibility for unwinding the data abort veneer's effects on the abort
stack. (How easy this is may vary between OSes.)


Errors
------

The following error codes are provisionally assigned:

  -1: OS-specific handler made invalid request.
   0: No error.
   1: Pre-indexed LDR/STR with base register = offset register and base
      register writeback, and extra code to deal with this case wasn't
      assembled.
   2: Post-indexed LDR/STR with base register = offset register.
   3: Use of a base register of R15 with base register writeback.
   4: Use of a base register of R15 in an LDM, STM or SWP instruction.
   5: Use of an offset register of R15.
   6: Instruction that both writes back to and loads its base register (can
      only occur if the "SuptLoadBaseWB" option is not specified).
   7: Use of an empty register list in an LDM or STM instruction (including
      the Thumb POP and PUSH instructions).
   8: Use of writeback in a "user bank" LDM or STM instruction.
   9: Instruction should not have been capable of generating a data abort.

However, the C header file is the authoritative source for these values.

Error code -1 is never produced on a normal call to the OS-specific handler.
However, if the OS-specific handler returns a value that it is not supposed
to, a second call to the OS-specific handler will be made, this time with
error code -1. The intent is to assist with debug during development: once
the OS-specific handler has been made to treat error code -1 as a fatal
internal error, incorrect behaviour by other, potentially more complicated
parts of it will be detected. (A drawback is that if the OS-specific handler
makes an invalid request in response to error code -1, an infinite loop will
result. However, if the system is this badly broken, something drastically
wrong is liable to happen anyway.)

The optional parameters will generally be valid when an error is reported,
with the following exceptions:

* If the "OS-specific handler made invalid request" error occurs, none of
  the optional parameters will necessarily be valid.

* The data transfer address requested by "PassXferAddress" will not always
  be valid if an error occurs: this is unavoidable because the correct data
  transfer address isn't even architecturally defined in many such cases.


System Environment Requirements
-------------------------------

1) The system must provide a Full Descending abort stack and initialise
   R13_abort to point at it. The capacity of the stack must be at least 32
   words (128 bytes), and the memory concerned must be "non-aborting" (i.e.
   privileged accesses to it must not generate aborts) at any time that a
   data abort is capable of occurring.

2) The data abort veneer code itself must be non-aborting at any time that a
   data abort is capable of occurring. If it supports multiple abort models,
   the data word saying which abort model is in use (the one specified by
   the "AbortModelVar" option) must similarly be non-aborting.

3) The data abort veneer will take care that at the time it calls the
   OS-specific handler, all its "live" data is either in callee-save
   registers for the chosen procedure calling standard or on the abort
   stack. If the OS-specific handler is to be called in abort mode, this
   should automatically ensure that the live R13_abort value is in a
   callee-save register; otherwise, R13_abort will be copied to a
   callee-save register before the OS-specific call and copied back
   afterwards.

   This means that the OS-specific handler can cause further aborts,
   provided it takes care that (a) the procedure calling standard's
   constraints are obeyed; (b) the procedure calling standard is one in
   which R13 is a callee-save register; (c) the contents of the current
   abort stack above R13_abort are preserved; (d) enough words are available
   on the abort stack.

4) It is the system's responsibility to ensure that FIQs cannot interfere
   with data abort processing. In particular, note that a FIQ can occur very
   early in the processing of a data abort, and in particular can occur
   after processing of the data abort entry sequence and before the hardware
   vector instruction at 0x00000010 or 0xFFFF0010 is obeyed. At this point,
   the data abort handler has had no chance to do anything at all, including
   saving the values in R14_abort and SPSR_abort. Accordingly, if a FIQ
   handler wants to do anything that could generate an abort, it must take
   care to preserve all state relevant to an outstanding abort before it
   allows the possibility of generating an abort itself.

5) If the OS-specific handler is to be called in supervisor or system mode,
   the relevant R13 value is set up correctly for the given procedure
   calling standard at any time that a data abort is capable of occurring.

6) If the OS-specific handler is to be called in abort mode, that the given
   procedure calling standard is compatible with its use of R13 as a Full
   Descending stack pointer, and that enough words are available on the
   abort stack to allow both for the data abort handler's requirement in 1)
   above and for any requirements the procedure calling standard has.

7) If the APCS_SWST calling standard is being used, that the word specified
   by the "HandlerSL" option contains a suitable stack limit for the
   OS-specific handler at all times that a data abort is capable of
   occurring.


Examples of Assembly-Time Options
---------------------------------

1) A system which will only be run on a bare ARM7TDMI, and which can fix up
   the reason for an abort based on the veneer-generated transfer address
   alone. (This needs a strategy along the lines of "if page containing
   transfer address is unmapped, map that page in; otherwise, map the next
   page in" to deal with the multi-word transfer cases.)

   The OS-specific handler wants to fix up the reason for the abort and use
   normal data abort actions if there is no error; if there is an error, it
   wants to tidy up and invoke a standard error routine to print out some
   diagnostics about register values.

     -PD 'VeneerEntry SETS "AsmDataAbortHandler"'
     -PD 'BaseUpdated SETL {TRUE}'
     -PD 'HandlerName SETS "CDataAbortHandler"'
     -PD 'HandlerCallMode SETS "Supervisor"'
     -PD 'PassXferAddr SETL {TRUE}'
     -PD 'ReturnNormal SETL {TRUE}'
     -PD 'ReturnAddress SETL {TRUE}'

2) A system which is to run on a variety of ARM processors from ARM7TDMI
   onwards, using system mode to run most privileged processes, and which
   will use an MMU Fault Address Register to determine which page needs
   mapping in. In the event of the abort indicating a real error rather than
   just a mapped-out page, however, it wants information about the aborting
   instruction and the processor state at the time of the abort for
   error-reporting purposes. (Errors will be reported by faking an entry to
   the standard undefined instruction trap.) The system also wants to use
   the veneer-supplied facility to select the correct abort model to use
   during system initialisation.

     -PD 'VeneerEntry SETS "AsmDataAbortHandler"'
     -PD 'BaseUpdated SETL {TRUE}'
     -PD 'BaseRestored SETL {TRUE}'
     -PD 'HandlerName SETS "CDataAbortHandler"'
     -PD 'HandlerCallMode SETS "System"'
     -PD 'PassSPSR SETL {TRUE}'
     -PD 'PassInstrAddr SETL {TRUE}'
     -PD 'PassRegDumpAddr SETL {TRUE}'
     -PD 'ReturnNormal SETL {TRUE}'
     -PD 'ReturnUndef SETL "0x00000004"'
     -PD 'AbortModelVar SETS "DataAbortModel"'
     -PD 'AbortModelInit SETS "AsmDataAbortInit"'