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

Reply to
Bhanu Nagendra P.
Loading thread data ...

"Bhanu Nagendra P." wrote in news:

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.

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


GCC for MSP430:
Reply to
Chris Liechti

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.

Reply to
Clifford Heath

... snip ...

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
 Click to see the full signature
Reply to

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.

Reply to
Clifford Heath

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.