Motorola MVME166IG/D2 - Manual (Page 84)

Using the 166Bug Debugger
4-14 MVME166 Single Board Computer Installation Guide
4
The following is an example of a routine which builds a separate vector table
and then moves the VBR to point at it:
*
*** BUILDX - Build exception vector table ****
*
BUILDX MOVEC.L VBR,A0 Get copy of VBR.
LEA $10000,A1 New vectors at $10000.
MOVE.L $80(A0),D0 Get generalized exception vector.
MOVE.W $3FC,D1 Load count (all vectors).
LOOP MOVE.L D0,(A1,D1) Store generalized exception vector.
SUBQ.W #4,D1
BNE.B LOOP Initialize entire vector table.
MOVE.L $10(A0),$10(A1) Copy breakpoints vector.
MOVE.L $24(A0),$24(A1) Copy trace vector.
MOVE.L $BC(A0),$BC(A1) Copy system call vector.
LEA.L COPROCC(PC),A2 Get your exception vector.
MOVE.L A2,$2C(A1) Install as F-Line handler.
MOVEC.L A1,VBR Change VBR to new table.
RTS
END
It may turn out that your program uses one or more of the exception vectors
that are required for debugger operation. Debugger facilities may still be
used, however, if your exception handler can determine when to handle the
exception itself and when to pass the exception to the debugger.
When an exception occurs which you want to pass on to the debugger; i.e.,
ABORT
, your exception handler must read the vector offset from the format
word of the exception stack frame. This offset is added to the address of the
166Bug target program vector table (which your program saved), yielding the
address of the 166Bug exception vector. The program then jumps to the
address stored at this vector location, which is the address of the 166Bug
exception handler.
Your program must make sure that there is an exception stack frame in the
stack and that it is exactly the same as the processor would have created for the
particular exception before jumping to the address of the exception handler.