deep

a Cross Development Platform for Java

User Tools

Site Tools


dev:crosscompiler:backend_arm:exceptions

This is an old revision of the document!


Exceptions

Terminology

  • ARM Exception: Exception which are specific to the ARM architecture.
  • Interrupt: A certain type of a ARM exception, caused by asynchronous events by external hardware.
  • Java Exception: Exception defined in the Java language specification. All Java exceptions are extensions of the class Throwable.
Types of Java-Exceptions

ARM Exceptions

Each ARM exception is caused by a synchronous or asynchronous event and generally causes the processor to switch its state and jump to its proper exception vector.

Invalid Link
PPC Exceptions and Interrupts

Exception classes and their corresponding exception methods have to be specified in the configuration. Instances of these classes are never created and therefore the object constructors are defined as synthetic and will not be translated into code.
The code generator has to create a special exception stack frame.
The ARM architecture reserves 4 bytes of memory at each exception vector. This is just enough to place a branching instruction there which causes the processor to jump to the right exception code.

Floats in Exceptions

Java Exceptions

Supervisor Call Exception

Each Java exception causes a ARM supervisor call exception. The supervisor call handler receives the thrown exception as a parameter in the first parameter register R0. The code generator has to make sure that this parameter is copied into R0 during the prolog of the program exception handler. The handler does the following:

  • Get address of causing instruction into variable addr from LR. Must happen first, as the next step uses LR as scratch register.
  • increment counter
  • Read instruction at this address minus 4, because LR points to next instruction
  • Determine from immediate value of instruction which kind of exception was thrown
  • If unchecked instruction: create exception such as ClassCastException, ArrayIndexOutOfBoundsException, etc.
  • copy parameter exception into register R0
  • copy parameter addr into register R1
  • branch to compiler specific subroutine handleException.

The supervisor call handler can use volatile registers freely. It further uses a few nonvolatile registers. However, these must be saved onto the stack at the start of the method and must be restored at the end.

Subroutine handleException

The following steps have to be taken:

  • Search end of method from addr (end at pattern 0x000000yy)
  • Search exception in exception table at end of method → start < addr < end && exception instanceof type.
  • If exception is found → put handler address into PC.
  • If not found →
    1. get address of call to this method (LR) from stack frame, copy into variable addr (in R1).
    2. replace LR in the stack frame with address of handleException subroutine.
    3. get address of epilog from exception table and branch to this address, this causes the unwinding of this method.

When the unwinding of a method is done, the flow of control automatically returns to handleException, because we modified the stack frame accordingly.

The figure below gives an example for the handling of exceptions.

Invalid Link
Example for handling of exceptions
dev/crosscompiler/backend_arm/exceptions.1566901747.txt.gz · Last modified: 2019/08/27 12:29 by ursgraf