Hello Developers,
First, thank you for supporting this project. I've been using C::B over the last few years on both Linux and Windows and I find it light and friendly.
I am currently using C::B as IDE for developing and debugging code on an MSP430-based embedded target. I would like to address here some issues and several amelioration that would help a better integration of the mspgcc toolchain in C::B (mspgcc + mspdebug). Of course I would be ready to contribute as far as I can.
Thank you in advance for your support,
Yordan
Here a list of issues/ameliorations:
1) CPU register is empty. How to setup correctly this window for mspgcc?
2) Impossible to select another debugger executable than GDB with the latest nightly build (would need to be msp430-gdb)
3) Need to send some default commands to mspdebug when msp430-gdb connects to it ("target remote :2000", "erase", "load"...). Would ideally like to write a new plugin for mspgdb with an extra button to load code to the remote, based on the debugger plugin. Would appreciate to get some support on this.
1) What is the output of the cpu registers gdb command? Does it look like the one for x86?
2) Have you tried "Settings -> Debugger -> GDB Debugger -> Your config -> Executable path" ?
3) Have you tried the settings in Project -> Properties -> Debugger?
1) What is the output of the cpu registers gdb command? Does it look like the one for x86?
-> The command passed from gdb to the proxy is "regs". It is works correctly when manually invoked through the debugger window command line. But there is no polling and display on the "CPU registers" window
2) Have you tried "Settings -> Debugger -> GDB Debugger -> Your config -> Executable path" ?
-> Thx, I did not catch that upda
3) Have you tried the settings in Project -> Properties -> Debugger?
Quote from: ywi on May 11, 2012, 03:28:42 PM
-> The command passed from gdb to the proxy is "regs". It is works correctly when manually invoked through the debugger window command line. But there is no polling and display on the "CPU registers" window
I said output, not the command. Paste it please.
1) What is the output of the cpu registers gdb command? Does it look like the one for x86?
-> The command passed from gdb to the proxy is "regs". It is works correctly when manually invoked through the debugger window command line. But there is no polling and display on the "CPU registers" window
2) Have you tried "Settings -> Debugger -> GDB Debugger -> Your config -> Executable path" ?
-> Thx, I did not catch that update. I can now configure my own debugger, but I get the following error message when I run it: "Starting the debuggee failed: Don't know how to run." I do not have this message with 10.05 ("do *not* run the debugee" option is disabled in both cases). When I use a custom command file (-x option) I don't get the previous error, I can talk to the proxy, erase and load the flash, but gdb does not seem to release the target from reset, so I cannot debug.
3) Have you tried the settings in Project -> Properties -> Debugger?
Yes, I call the proxy as an additional shell command, but it does not seem to work. But I still need a separate button to load the flash.
> regs
Use 'info registers'.
pc/r0: 9800 sp/r1: 1cfa sr/r2: 0000 r3: 0000
fp/r4: 0000 r5: 5a8c r6: 0000 r7: 0000
r8: 0000 r9: 0000 r10: 0000 r11: 0000
r12: 0000 r13: 0022 r14: 0182 r15: 0519
Quote from: ywi on May 11, 2012, 04:08:20 PM
-> Thx, I did not catch that update. I can now configure my own debugger, but I get the following error message when I run it: "Starting the debuggee failed: Don't know how to run." I do not have this message with 10.05 ("do *not* run the debugee" option is disabled in both cases). When I use a custom command file (-x option) I don't get the previous error, I can talk to the proxy, erase and load the flash, but gdb does not seem to release the target from reset, so I cannot debug.
Steps to reproduce please, because I don't understand much of what you've written.
Keep in mind that I'm not embedded developer and proxy/reset/erase-load doesn't mean much to me.
Case 1 :
=====
I configure the following :
Settings -> Debugger -> GDB Debugger -> MSPGDB -> execute path : /usr/local/bin/msp430-gdb
Settings -> Debugger -> GDB Debugger -> MSPGDB -> arguments :
I run the debugger :
...
Starting debugger: /usr/local/bin/msp430-gdb -nx -fullname -quiet -args /projects/cb/test/bin/Debug/test
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2
Starting the debuggee failed: Don't know how to run. Try "help target".
Debugger finished with status 0
Case 2
=====
a) I configure the following :
Settings -> Debugger -> GDB Debugger -> MSPGDB -> execute path : /usr/local/bin/msp430-gdb
Settings -> Debugger -> GDB Debugger -> MSPGDB -> arguments : -x /usr/local/msp430/gdb.ini
b) gdb.ini contains commands for the mspdebug proxy :
target remote :2000 // connect to the proxy
erase // erase flash
load // load executable to flash
continue // release CPU from reset
c) I run the proxy, then I run the debugger:
The debugger connects successfully to the proxy, the commands are passed to the proxy and executed successfully. But then I lose control on gdb (I can push the buttons, write commands in the command line, but they are not taken into account).
"do *not* run the debugee". It is disabled in both cases.
Have you tried to setup the remote debugging options for your project in Project -> Properties -> Debugger-> Remote connection?
p.s. All please enable the full log in the Settings->Debugger, before posting more logs from the debugger...
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
Does it work if you execute the same commands in a command line gdb?
Also what happens if you put a breakpoint before you start the debugger?
It works OK as command line and with 10.05. I will be able to answer the second question on Monday. Thx.
Can you post the log from command line debugger?
But make sure to execute all gdb commands C::B is executing...
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.
Hm, as far as I can see in your previous logs continue is used, as it should.
There is no run in the log.
"do *not* run the debuggee" - does not run the debuggee, just starts the debugger, sets the breakpoints and probably connects to the target, then the user has to press the continue button in order to start debugging.
How do you burn something to a flash? I don't think C::B knows how to do it.
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.
For the burning: Then you need to put the commands in a file and then use the source command in combination with the 'do not run mode'.
For the run command: I see no remote debugging commands, so I guess you've not set them and you're in native/local debugging mode, thus run is the normal command to use.
Yes, I already used successfully a file at gdb start to run particular commands. But still sometimes gdb is launched and reprogramming the flash is not necessary. How to distinguish between both? Usually tools working on remote targets have separate buttons for connect to target and burn.
For your second comment, could you give me some details on where to set "native" and "remote" specific mode parameters?
Thx.
Quote from: ywi on May 14, 2012, 11:23:21 PM
Yes, I already used successfully a file at gdb start to run particular commands. But still sometimes gdb is launched and reprogramming the flash is not necessary. How to distinguish between both? Usually tools working on remote targets have separate buttons for connect to target and burn.
Do you see the edit box at the bottom of the debugger's log?
There you can enter commands, so if you're in do-not-run mode you can start gdb then if necessary you can execute the source command manually and then you can start debugging.
Isn't this what you want?
Quote from: ywi on May 14, 2012, 11:23:21 PM
For your second comment, could you give me some details on where to set "native" and "remote" specific mode parameters?
I already have shown you - in the project -> properties -> debugger -> remote...
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 guess you have to set the proper disassembly flavor.
See here: http://forums.next.codeblocks.org/index.php/topic,16336.msg110619.html#msg110619
I don't know what is the correct/proper disassembly flavor, read the manual of you gdb about it.
If not you'll have to modify the cpu registers parser and provide a patch.
OK. Thx for this overview of the debugger configuration possibilities.
Is there any simple codeblocks plugin example (ideally a toolbar with just one button that when pushed calls a shell command) ? It will be quite easy to build a remote connect and flash burn contrib plugin out of it.
Thanks.
Quote from: ywi on May 18, 2012, 05:43:59 PM
(ideally a toolbar with just one button that when pushed calls a shell command) ? It will be quite easy to build a remote connect and flash burn contrib plugin out of it.
For such purposes, there is the Tools / Tools+ plugin that can do such quite handy. No need for another plugin.
Well, that's great, thanks. Would be nice this menu to create its own toolbar.
I come back to a request for monitoring specific remote registers (not only the remote CPU registers). What I basically need is to be able to load at C::B start a memory map description file of volatile variables that gdb will have to update at each step/bkp. Any suggestions?
Quote from: ywi on May 18, 2012, 08:50:05 PM
I come back to a request for monitoring specific remote registers (not only the remote CPU registers). What I basically need is to be able to load at C::B start a memory map description file of volatile variables that gdb will have to update at each step/bkp. Any suggestions?
Use the debugger initialisation commands and (if needed) the debugger console for that purpose.
This is not quite convenient. It should behave like a watch, i.e read and display automatically the list of remote registers (addresses). GDB should execute command "x/b <addr>" for every address of the registers address list when a bkp/step is reached.
I guess you can use python enabled gdb and use some fancy python scripts...
That is an interesting option indeed, but maybe too fancy for me for the moment. Is there any possibility to pass commands to the GDB launched by C::B by an external shell command?
No, but you can load a file.
I found a solution using just the watch mechanism of C::B. Actually gdb will execute
output ...
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
toto
blabla
ole
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
One (probably) last question : is it possible to automatically load a watch file at the beginning of a debug session (or project open) ?
Are you aware of the .gdbinit and .mspdebug files where some presets can be made? regards, Kees