From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott A Sumner To: insight@sourceware.cygnus.com Subject: Re: Wrong Program Counter value when encountering a breakpoint -> SIGILL Date: Mon, 22 May 2000 14:35:00 -0000 Message-id: <20000522.172439.-101741.2.sasumner@juno.com> X-SW-Source: 2000-q2/msg00201.html 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.