Table of Contents
Advertisement
Using The 162Bug Debugger
4
4-14
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
LEA
$10000,A1
MOVE.L
$80(A0),D0
MOVE.W
$3FC,D1
LOOP
MOVE.L
D0,(A1,D1)
SUBQ.W
#4,D1
BNE.B
LOOP
MOVE.L
$10(A0),$10(A1)
MOVE.L
$24(A0),$24(A1)
MOVE.L
$BC(A0),$BC(A1)
LEA.L
COPROCC(PC),A2
MOVE.L
A2,$2C(A1)
MOVEC.L
A1,VBR
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 162Bug target program vector table (which your program
saved), yielding the address of the 162Bug exception vector. The program
then jumps to the address stored at this vector location, which is the
address of the 162Bug exception handler.
Your program must make sure that there is an exception stack frame in the
stack. It must be exactly the same as the processor would have created for
the particular exception before jumping to the address of the exception
handler.
Get copy of VBR.
New vectors at $10000.
Get generalized exception vector.
Load count (all vectors).
Store generalized exception vector.
Initialize entire vector table.
Copy breakpoints vector.
Copy trace vector.
Copy system call vector.
Get your exception vector.
Install as F-Line handler.
Change VBR to new table.
Computer Group Literature Center Web Site
Advertisement
Table of Contents
