The most likely place to look is the module msp430-tdep.c in the gdb
distribution. There are apparently two issues.
The first is that the code that grovels around in the stack to unwind
frames apparently has a bug. I believe it did work
in the earlier versions (but I'm not sure). In any case it seems to not
correctly identify the call frames. The second
problem is that the breakpoint is interpreted as a normal exception.
This means that gdb doesn't quite do the right
thing when breakpoints occur.
If you're really going to look at this code, I'd recommend using "target
sim" rather than an actual target. This makes
it easier to reproduce any odd behavior. I've ported GDB in the past
(for the HP/ST LX VLIW processor). GDB
is resasonably set up to debug itself. If you start a host gdb session
in the directory where the target gdb is built
then you can switch back and forth.
I've confirmed that the incorrect behavior happens both in the
simulation target and the real target (gdb-proxy) so the
problem is not in the proxy.
Geoffrey
