I set the remote connection in Project -> Properties -> Debugger-> Remote connection. It works. I not have the "Don't know how to run" error anymore (Case 1, default setting and not using a command file). I can see the gdb connect to the proxy and send the "continue" command. I then lose control over the command line and the buttons. I can stop gdb only by killing the proxy.
Here is the full log :
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: /projects/cb/test/
Adding source dir: /
Adding file: /projects/cb/test/bin/Debug/test
Changing directory to: /projects/cb/test/.
[debug]LD_LIBRARY_PATH=.:/projects/cb/test:/usr/local/lib:
[debug]Command-line: /usr/local/bin/msp430-gdb -nx -fullname -quiet -args /projects/cb/test/bin/Debug/test
[debug]Working dir : /projects/cb/test
Starting debugger: /usr/local/bin/msp430-gdb -nx -fullname -quiet -args /projects/cb/test/bin/Debug/test
done
[debug]Reading symbols from /projects/cb/test/bin/Debug/test...done.
[debug](gdb)
[debug]> set prompt >>>>>>cb_gdb:
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Connecting to remote target
Setting breakpoints
[debug]>>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.2
[debug]Copyright (C) 2010 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law. Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=msp430".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off
Debugger name and version: GNU gdb (GDB) 7.2
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]No symbol "disassembly" in current context.
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /projects/cb/test/
[debug]>>>>>>cb_gdb:
[debug]> directory /
[debug]>>>>>>cb_gdb:
[debug]> target remote tcp:127.0.0.1:2000
[debug]Queued:[tty /dev/pts/3]
[debug]_reset_vector__ () at ../../../gcc-4.5.3/gcc/config/msp430/crt0.S:118
[debug]/home/toto/msp430/gcc-4.5.3/gcc/config/msp430/crt0.S:118:3824:beg:0x9800
[debug]>>>>>>cb_gdb:
Connected
[debug]> tty /dev/pts/3
At /home/toto/msp430/gcc-4.5.3/gcc/config/msp430/crt0.S:118
[debug]> tty /dev/pts/3
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> continue
EDIT:
Please use code-tags if you post such an amount of log entries or source-code the next time, because it's much more readable.
I changed your post.
Jens
This is the minimal commands executed on msp430-gdb
Reading symbols from /projects/cb/test/bin/Debug/test...done.
(gdb) target remote :2000
Remote debugging using :2000
_reset_vector__ () at ../../../gcc-4.5.3/gcc/config/msp430/crt0.S:118
~/msp430/gcc-4.5.3/gcc/config/msp430/crt0.S:118:3824:beg:0x9800
(gdb) break *0xdcd0
Breakpoint 1 at 0xdcd0: file /projects/cb/test/test, line 79.
(gdb) continue
Continuing.
Breakpoint 1, plat_mpipe_rx_isr (id=2) at /projects/cb/test/test.c:79
/projects/cb/test/test.c:79:2857:beg:0xdcd0
(gdb)
I found that the difference with the nightly is that it sends the command "run" rather than "continue" to continue after a break. msp430-gdb does not support (for some reason) the command "run". I think we can consider this is more a problem with msp430-gdb than the nightly, unless there some other reason to differentiate both.
Maybe at this point you can explain to me the usage of the config "do *not* run the debuggee".
Also, for remote target debugging it is mandatory to have two separate buttons in the debugger toolbar, one to burn the code on the remote's flash, the other to start/continue. Burning takes some time and you do not want to burn every time you start a debugging session.
I would appreciate your suggestions on how to display the regs information in the appropriate debug window.
Than you.
The latest nightly debugger plugin passes command "run" instead of "continue" when the run/continue button is pressed:
Debugger name and version: GNU gdb (GDB) 7.2
[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor intel
[debug]No symbol "disassembly" in current context.
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Function "__cxa_throw" not defined.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory /projects/test/
[debug]>>>>>>cb_gdb:
[debug]> directory /projects/
[debug]>>>>>>cb_gdb:
[debug]> tty /dev/pts/3
[debug]Queued:[tty /dev/pts/3]
[debug]>>>>>>cb_gdb:
Continuing...
[debug]> run
[debug]Don't know how to run. Try "help target".
[debug]>>>>>>cb_gdb:
Starting the debuggee failed: Don't know how to run. Try "help target".
[debug]> quit
Debugger finished with status 0
For burning the flash, gdb send specific commands (erase, load, ...) to the debugger proxy, which is himself connected to a programmer.
OK, I have all information on the configuration possibilities of the debugger. It can partially cover remote debugging needs. As I mentioned, sometimes gdb is launched and reprogramming the flash is not necessary, so a separate toolbar button to burn the flash would be a plus.
Could you help me on the registry window problem? Here is the information printed with command "info registers":
pc/r0: a702 sp/r1: 2bb0 sr/r2: 001b r3: 0000
fp/r4: ffff r5: 5a0c r6: ffb4 r7: ffff
r8: ffff r9: ffff r10: ffb4 r11: ffff
r12: 0001 r13: 0000 r14: 0340 r15: 0000
Thanks.
I found a solution using just the watch mechanism of C::B. Actually gdb will execute
where "..." is the content of a line of the watch file. For example when variables toto, blabla, ole are watched, the content of the watch file is
Now, it is possible to add more arguments in the watch file, or read absolute addresses instead of symbols. For example output /x (my_type)*0x1234 will read at address 0x1234 and interpret it as a variable of type my_type in hexadecimal. Subsequently it is possible to read remote content by 1) defining a structure containing the remote registry (let say msp430_regs_t in my case) 2) adding in a default watch file
/x (msp430_regs_t)*0xXXXX
where 0xXXXX is the registry base. I checked that this is correctly interpreted by C::B.
Regards, Yordan