Wrong Program Counter value when encountering a breakpoint -> SIGILL

[Paul_Heijman at eu dot omron dot com]

Hi all,

I'm at the moment working on the last few bugs of my mc68340-stub.
My biggest problem now, is the following:

When I set a breakpoint at a certain line or assembly instruction, and I press
'continue', GDB doesn't stop at the right address.
If it, for example, had to stop at 0x33260, it stops at 0x33262. (always a
difference of +2 bytes!).

I know GDB sets breakpoints by replacing the original code with a TRAP #1
instruction (2 bytes of machine code) and therefore this could be the reason why
the program counter indicates a value of +2 above the breakpoint address.
In the stub, there seems to be some kind of compensation for that. When the stub
receives the continue or step command, it checks the frame cache for an existing
version of the breakpoint-exception-frame. Thereby, it expects an offset of +2.
But what if the breakpoint hasn't been encountered yet and doesn't exist in the
frame cache?

Anyway, it keeps on going wrong, and results (offcourse) in a SIGILL exception
(Illegal Instruction) because the program counter is pointing somewhere between
two instructions.

Anyone have a clue what I might have done wrong in my stub, because I assume
it's not a problem of GDB itself, since I never heard someone complain about it?
I was thinking of simply subtracting '2' from the PC value whenever a breakpoint
exception occurs, but I think this is a dirty solution (if it works) and I
really want to find the cause.

greetings,
Paul.
-