breakpoints with MSP430-gdb

Hello,
I am trying to debug code running on an MSP430 over a parallel port with
my
own version of gdbproxy. For most part it work fine. However when I set
multiple breakpoints, then on hitting the first breakpoint gdb
instructions the proxy to remove ALL breakpoints.

I have two questions:
* Should (msp430-) gdb really try to remove a breakpoint once it is hit?
* Even if so why does it try to remove all other breakpoints as well?

Here is the transcript from the gdb side:

========================================================
Commands to set the 2 Breakpoints set:

(gdb) break *0xe006
Breakpoint 1 at 0xe006
(gdb) break *0xe012
Breakpoint 2 at 0xe012

Command to Start execution:

(gdb) continue
Continuing.

Sending packet: $Z0,e006,2#0f...Ack  <------ gdb setting breakpoints
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $Z0,e012,2#0c...Ack
Packet received: OK

Sending packet: $Hc0#db...Ack
Packet received:
Sending packet: $C06#a9...Ack      <--------- starts execution
Packet received: T0500:06e0;04:0000;

Program received signal SIGTRAP, Trace/breakpoint trap. <---- bkpt hit
Sending packet: $z0,e006,2#2f...Ack   <---- gdb asks bkpt 1 to be removed
Packet received:
Sending packet: $z0,e012,2#2c...Ack   <---- gdb asks bkpt 2 to be removed
Packet received:

============================================================================

Thanks in advance!
-Bhanu

"Bhanu Nagendra P." <bpisupat@cs.indiana.excludethis.edu> wrote in
news:Pine.GSO.4.58.0409211756370.22839@wobbegong.cs.indiana.edu: 

> Hello,
> I am trying to debug code running on an MSP430 over a parallel port
> with my
> own version of gdbproxy. For most part it work fine. However when I
> set multiple breakpoints, then on hitting the first breakpoint gdb
> instructions the proxy to remove ALL breakpoints.

and it will install them all again when running again.

that's probably a behaviour that comes from systems that allow RAM 
locations to be patched with a sowftware interrupt instruction that jumps 
to the debugger. then these instructions are removed, so that inspecting 
the memory at the breakpoint gives the correct result.

> I have two questions:
> * Should (msp430-) gdb really try to remove a breakpoint once it is
> hit? * Even if so why does it try to remove all other breakpoints as
> well? 

if you know of a way to convince GDB to not do that, i'd happy to hear it.

chris


> Here is the transcript from the gdb side:
> 
> ========================================================
> Commands to set the 2 Breakpoints set:
> 
> (gdb) break *0xe006
> Breakpoint 1 at 0xe006
> (gdb) break *0xe012
> Breakpoint 2 at 0xe012
> 
> Command to Start execution:
> 
> (gdb) continue
> Continuing.
> 
> Sending packet: $Z0,e006,2#0f...Ack  <------ gdb setting breakpoints
> Packet received: OK
> Packet Z0 (software-breakpoint) is supported
> Sending packet: $Z0,e012,2#0c...Ack
> Packet received: OK
> 
> Sending packet: $Hc0#db...Ack
> Packet received:
> Sending packet: $C06#a9...Ack      <--------- starts execution
> Packet received: T0500:06e0;04:0000;
> 
> Program received signal SIGTRAP, Trace/breakpoint trap. <---- bkpt hit
> Sending packet: $z0,e006,2#2f...Ack   <---- gdb asks bkpt 1 to be
> removed Packet received:
> Sending packet: $z0,e012,2#2c...Ack   <---- gdb asks bkpt 2 to be
> removed Packet received:
> 
> =======================================================================
> ===== 
> 
> Thanks in advance!
> -Bhanu
> 



-- 
GCC for MSP430: http://mspgcc.sf.net
Chris <cliechti@gmx.net>

Bhanu Nagendra P. wrote:
> ...on hitting the first breakpoint gdb
> instructions the proxy to remove ALL breakpoints.
> * Should (msp430-) gdb really try to remove a breakpoint once it is hit?

It's not necessary on the MSP430 if you're exclusively using hardware
breakpoints. Most devices don't have enough of these though, so gdb
implements software breakpoints. These are implemented by replacing
the opcode by a trap instruction of some sort. The trap must be removed
either upon stopping, or before continuing.

When I implemented this in my 'HC11 debugger DB11, I removed only the
current breakpoint. When you continue, I used branch prediction to set
a BP at the next instruction to enable a single-step. When that breaks,
replace the original breakpoint and remove the single-step BP before
continuing again.

In order for memory-examine and disassembly to show correct instructions
rather than breakpoints, I diverted all memory-read requests via the
breakpoint table which allowed DB11 to pretend to read the original
opcode instead of the breakpoint instruction. Could be confusing if
you have self-modifying code (so the BP table had the wrong saved
opcode), but I never did. This could be the reason that GDB removes
all breakpoints however - saves the need for read-diversion and saves
the actual opcode even if that changes from time to time.

Clifford Heath.

Clifford Heath wrote:
> 
... snip ...
> 
> When I implemented this in my 'HC11 debugger DB11, I removed
> only the current breakpoint. When you continue, I used branch
> prediction to set a BP at the next instruction to enable a
> single-step. When that breaks, replace the original breakpoint
> and remove the single-step BP before continuing again.

I did much the same in DDTZ for CP/M (which is available in source
on my site).  However I would hardly call it branch prediction -
it is simply a matter of knowing all the possible next instruction
locations for any instruction.  This has to include such things as
returns.  There was no such thing as a permanent break point in
that, unless you patched in the appropriate instruction.

-- 
 "It is not a question of staying the course, but of changing
  the course"                        - John Kerry, 2004-09-20
 "Ask any boat owner the eventual result of continuing the
  present course indefinitely"    - C.B. Falconer, 2004-09-20

CBFalconer wrote:
> However I would hardly call it branch prediction -
> it is simply a matter of knowing all the possible next instruction
> locations for any instruction.

Understand. That can work also, though to predict the location of a
branch in the 68HC11 you sometimes need to consider calculated branches,
jump tables, etc, so there are very many possible "next instructions".
The only solution was to actually consider the addressing mode and
compute the actual next, which sometimes requires a memory fetch from
a computed location. And IIRC there was still a possibility that it
wouldn't work if a hardware interrupt was waiting; or did those all
occur *after* the instruction after RTI? I forget.

Clifford Heath.