This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
RE: exceptionHandler for 68K
- To: "'gdb mail list'" <gdb at sourceware dot cygnus dot com>
- Subject: RE: exceptionHandler for 68K
- From: David Williams <davidwilliams at ozemail dot com dot au>
- Date: Fri, 3 Dec 1999 10:12:57 +1100
- Organization: DLC software P/L
- Reply-To: "davidwilliams at ozemail dot com dot au" <davidwilliams at ozemail dot com dot au>
Hi,
Although the debug stubs distributed with GDB can be used without
modification, there is no reason why you must do so.
Exception handling mechanisms are target dependent. If you're happy
with the exception mechanism you are currently using (or the one you
have designed, if you're not that far), In my opinion it is better to
adapt the debug stubs exception handler installation code rather than
to force your system to match.
Good Advice, and in fact what I was already considering. However I wish to
understand the exisiting m68k-stub.c better to decide if what is being done
is useful and worth adapting. Please note my target (68EZ328) has a 68000
core, not CPU32, so when exceptions occur there is no vector number stored
on the stack.
I get the idea of what the m68k-stub.c (supplied with gdb4.18) is trying to
do without understanding the full detail. The 68000 does not provide the
vector number when an exception occurs. To get arround this the stub
assumes that you orgainise the real 68K vectors to point to a table of 'jsr
handler' op-codes. Then when the exception occurs the CPU stacks the
current PC(program counter) and SR(status register) looks up the vector and
loads the PC with the value in the vector. The new PC will be somewhere in
the jsr table. The CPU then executes the jsr in the table which causes the
CPU to stack the return address (location in the jsr table) and then jump
to the exception handler. My problem is that I dont understand where this
table of jsr's is located...
The m68k-stub has code to determine the exception number by taking the
return address on the stack (the return address is the location in the jsr
table) and adding 1530 and then dividing by 6.
The relevent comments in the source are
"Some explanation is probably necessary to explain how exceptions are
handled. When an exception is encountered the 68000 pushes the current
program counter and status register onto the supervisor stack and then
transfers execution to a location specified in it's vector table. The
handlers for the exception vectors are hardwired to jmp to an address given
by the relation: (exception - 256) * 6. These are decending addresses
starting from -6, -12, -18, ... By allowing 6 bytes for
each entry, a jsr, jmp, bsr, ... can be used to enter the exception
handler. Using a jsr to handle an exception has an added benefit of
allowing a single handler to service several exceptions and use the return
address as the key differentiation. The vector number can be computed from
the return address by [ exception = (addr + 1530) / 6 ].
The sole purpose of the routine _catchException is to compute the exception
number and push it on the stack in place of the return address. The
external function exceptionHandler() is used to attach a specific handler
to a specific m68k exception."
Any help would be appreciated.
All that being said...
It's been a long time since I've used the m68k, but if I remember
correctly the addresses of exception handlers are stored in a 256
entry table, the address of which is stored in a exception vector
table base register.
In C, you might do something like this to install an address:
void *exc_tbl[256];
void
exceptionHandler(int vec, void *addr)
{
exc_tbl[vec] = addr;
}
In assembly, the code might be something like this:
#
# Inputs:
# d0 - vector
# d1 - address of exception handler
# a0 - address of exc_tbl
#
move.l %d1,(%a0,%d0.l*4)
Thanks for the code, unfortunately this does not address my problem - see
notes above.