Re: Wrong Program Counter value when encountering a breakpoint -> SIGILL

[Scott A Sumner <sasumner at juno dot com>]

Paul,

I think you're on the right track.  Why do you think that the "subtract
2" solution is "dirty"?  I don't think it's so bad--it's what I do in my
68332 stub (I'm guessing that the 68340 is also a member of the CPU32
family of processors).  Here's the comment--which pretty much says it
all--and the C code that does it for me:

/* the exception frame contains a program counter (which at this point
has been copied to gdb_register_file) that is 2 bytes past the trap #1
instruction that gdb inserted as a temporary breakpoint; need to
decrement the pc in the gdb register file by 2 so that upon return the
real instruction (temporarily covered by the trap #1) gets executed */

gdb_register_file[PC] -= 2;

If you want too see the surrounding code, you should be able to find it
on www.sourceforge.net ; search on "gdbstub" when you get there and then
do some looking for the cpu32 stub.

Regards,
Scott



On Mon, 22 May 2000 16:29:33 +0100 Paul_Heijman@eu.omron.com writes:
> 
> 
> 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.