Debugging MSP430 from within C::B

[oBFusCATed]

BTW, has any one working on the debugger branch looked at bug 017461 ""Additional GDB Commands -> Before Connection" broken"? I discovered that problem while trying to setup the target board using GDB commands in that setting.  The bug report was submitted by my colleague.

I've tried to reproduce this problem, but I couldn't. Is this windows only bug?

Here is the output of the three commands I've added:

Code

>>>>>>cb_gdb:>>>>>>cb_gdb:
> info program
The program being debugged is not being run.
>>>>>>cb_gdb:
> info breakpoint
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  exception throw
>>>>>>cb_gdb:
> info threads

[pfong]

I saw this problem on Ubuntu.
I tried to define a function in the "Additional GDB Commands -> Before Connection".  For example for OpenOCD:
define reload
        monitor jtag_khz 500
        monitor reset init
        monitor jtag_khx 10000
        load
end

The function would not be defined in GDB.
It worked fine if I put the same thing in the global compiler/debugger settings under "Settings"->"Compiler/Debugger"->"Debugger settings"->"Debugger initialization commands"

[oBFusCATed]

pfong: have you checked if the previous two bugs are fixed in the latest revisions?

[pfong]

I did a quick test with the nightly on Sept 19 SVN 6608 debugger branch on Windows.
When do not run debugee is checked, C::B now correctly sends "cont" instead of "run" the first time you press run/continues.
Breaking while the target is running seems to work fine as well.

However, I did notice that it did not seem to handle next or step correctly.  I had stopped at a while(1) loop in my target.  When I pressed next or step in the toolbar it would send next or step to GDB but did not realize when GDB returned (the command input box was not re-enabled).  It did work correctly when I typed next or step into the command box though.

[oBFusCATed]

Can you provide the debug log?
Also does it work in normal console app debug session?

[pfong]

Ok, I did a little more experimenting with a regular native console app.
Next never returns control in GBD on a while(1) loop.  This seems correct because you never get to the next line.
So the C::B behavior when you press "Next" is correct.  The UI goes into the running state and you can break by pressing the break button.
The behavior when you execute next by typing it in the command box is incorrect or at least undesirable.  The UI does not go into the running state, so you cannot break by pressing the break button (or any other way as far as I can tell).

In both cases the only thing I see in the debugger log is "next".