RE: exceptionHandler for 68K

[David Williams <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.