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

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

[Scott A Sumner]

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.
 

Wrong Program Counter value when encountering a breakpoint -> SIGILL

[Paul_Heijman]

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.
-