breakpoints with MSP430-gdb

"Bhanu Nagendra P." wrote in news: snipped-for-privacy@wobbegong.cs.indiana.edu:

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.

chris

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.

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

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.