GDB over serial ready or coming?
Rayman
Posts: 14,665
Was reading a bit about GDB (GNU debugger) and also WinGDB.
WinGDB should allow me to use GDB inside of Visual Studio over serial connection.
The price isn't so bad and there's also a free version (although limited).
Is GDB over serial connection something that is being developed?
Is it already available?
WinGDB should allow me to use GDB inside of Visual Studio over serial connection.
The price isn't so bad and there's also a free version (although limited).
Is GDB over serial connection something that is being developed?
Is it already available?
Comments
(1) Compile your program with -g and (preferably) with minimal optimization. In theory you can debug optimized programs, but the optimizer moves code around, and it can get very confusing. The debugger in theory works in LMM, CMM, and XMM modes, but XMM is extremely restricted because only 2 breakpoints are available (the debugger can't write into flash or EEPROM, and has to rely on a small table of breakpoints).
(2) Run propeller-load with -g and -r, and without -t, to load the program and get it ready for debugging.
(3) Launch propeller-elf-gdb, set any breakpoints you want, and then type "c" (for continue). ^C will often work to break the program, but isn't 100% reliable (if the program is stuck in a loop outside of the LMM interpreter it can't be interrupted).
Here's a sample program:
#include <stdio.h> void main() { printf("hello, world!\n"); printf("goodbye, world!\n"); }And here's a compile and debug session with it (I'm using Linux, but Windows would be the same except for the prompt):
$ propeller-elf-gcc -g -o hello.elf hello.c $ propeller-load -bc3 hello.elf -r -g Propeller Version 1 on /dev/ttyUSB0 patching for debug at offset 0x68 Loading hello.elf to hub memory 6516 bytes sent Verifying RAM ... OK $ propeller-elf-gdb hello.elf GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=propeller-elf". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... 0x000005b0 in ?? () Reading symbols from /tmp/hello.elf...done. (gdb) break main Breakpoint 1 at 0x674: file hello.c, line 4. (gdb) c Continuing. Breakpoint 1, main () at hello.c:4 4 printf("hello, world!\n"); (gdb) next Breakpoint 1, main () at hello.c:4 4 printf("hello, world!\n"); (gdb) next hello, world! 5 printf("goodbye, world!\n"); (gdb) next goodbye, world! 6 } (gdb)Eric
Not sure I can make this work with WinGDB though...
WinGDB talks about serial debugging, but it seems what the really mean is debugging using an OpenOCD JTAG interface.
Hmmm. I just tried to run it, and it didn't install with my version of p2test build. It's not in /opt/parallax/bin:
My version:
And, it doesn't choke when I pass it -mp2 as an option, so I assume that I have the correct branch installed. What should I try next?
Make sure you have no changes in your tree. Then in propgcc ....
$ hg pull
$ hg update p2test
$ ./jbuild.sh 6 rm-all
I've been stepping through some CMM and LMM P1 code tonight with SimpleIDE (don't tell Parallax I was goofing around LOL).
I need a way to distinguish debug info from console info. Any ideas? Wish there was a marker for all lines of gdb output.
Are you sneaking a GDB interface into SimpleIDE?
I just pulled and built propside again, it's looking very good.
Being a sick human being I loaded it up with some JavaScript!
Well, JS has a C like syntax so that looks pretty good as well. Starts me thinking, could I hack propside to do a better job of JS highlighting? Could it highlight matching brackets and braces (There tends to be rather more of those in JS)? Could I get it to run jslint and jump to lines with errors like it does with gcc error output? Could I get it to run the JavaScript by starting up node.js? could I get the node.js ouput into the serial terminal window? .....
Am I sick?
I think not. One thing I want to do is explore systems that are basically Propeller -> serial link -> webserver -> browser. Where the serial and web server are done in JavaScript running under node.js. In that kind of set up we need to develop C/C++ for the Prop and JavaScript for the server and browser client side. Would be neat to do it all in one IDE. SimpleIDE:)
Excuse me whilst I start butchering your code....
I had to run it as follows:
I also notice that this error message seems out of date for propeller-load:
When I run it with the same program, then I get the following when I set "break main":
From the link below, it looks like the expat-dev library needs to be installed. Once intalled it fixed that problem. Of the unmentioned dependencies, it looks like the total is (that I've run across) are: bison, libncurses-dev, and expat-dev
http://stackoverflow.com/questions/5665800/compiling-gdb-for-remote-debugging
One thing that would be helpful in this area is a "unified" gdb that takes care of downloading. It would make it easier to integrate into IDE's, I think.
It probably can be made to work; WinGDB itself shouldn't care how gdb is talking to the target. But I don't know exactly how WinGDB works, so I don't know how much effort it would be to get this going.
Eric
It's possible to build propeller-elf-gdb so that it can load P1 LMM files. But when I looked into extending this, there were a huge number of cases to support (P1 and P2 are different, and each has LMM and XMM with all the possible board configurations). I didn't like the idea of duplicating that much code between propeller-load and propeller-elf-gdb :-(. Sometime maybe we can come up with a shared library for both tools, but for now I think IDEs should be able to automate loading with propeller-load before running gdb; or we could write a small batch file/shell script to do this.
Eric
"The procedure entry point libintl_setlocale could not be located in the dynamic link library libintl-8.dll"
Thought maybe my GIMP install was messing it up, but that's not it.
It is finding the libintl-8.dll in propgcc folder...
The problem I had with gdb was that the .gdbinit file is not in my path. I had to add "target remote | gdbstub -p <port>".
Heater,
The gdb stepping support has been in SimpleIDE for a while, but I didn't keep up with Eric's load method change. I don't expect it to be a fully developed feature for a while.
I assume you remember that "hg update spinside" gets the latest version. Once this stage of SimpleIDE is done, spinside will be rolled into the default branch.
Since you're looking at language stuff, I guess you've seen the builder class by now. That encapsulates lots of language specific build stuff, but there is still substantial cruft in the language selection. That cruft is the main barrier to adding new languages at the moment. I'd like to add an "other build" method that could be used for doing make or some other build.
BTW, your javascript idea is not totally crazy. I'm interested in the possibility of web based gui of sorts, but there are so many security concerns with direct system access. I looked at that briefly over the last few weeks. One fellow created a client side plug-in called "seriality" https://code.google.com/p/seriality/ .... I haven't looked at it too deep. There are several Arduino related Javascript projects.
Thinking about security and ease of use, it seems like having a "local" web server that runs PHP would be a fair solution, but as in anything else with direct system access, that would require some installation and configs.
To be honest, no, I have not looked so hard as to see the "builder class" yet.
I can see a little problem with my plan, one would have to have a C/C++ project
open for the Propeller stuff but at the same time be editing a JS project for
the server side things.
As for security and WEB access, "having a "local" web server that runs
PHP" is no more secure than having a web server in node.js and server side
scripts in JavaScript. Just a different language.
Thing is you don't need to install Apache or nginx or whatever web server. Just run your 100 lines of JavaScript under node.js. Bingo! you have a web server, https, and a serial link to your Propeller.
I have been meaning to post a description of such a set up for a while now.
Hmm. I guess I misunderstood about JavaScript having any server side ability - I thought it was all client. That makes sense though since AJAX uses the network interface.
I look forward to your description.
Thanks.
So there you have a super simple way to create a WEB server. Like 10 lines of code.
But then:
1) Forget all that AJAX stuff. With node.js we can do HTML 5 websockets really easily. So we have a hot line between server and browser.
2) Node.js has already thousands of add on modules, which include serial communication.
Bingo, we have a hot line from Propeller to browser.
Check this out:
http://nodejs.org/
http://www.youtube.com/watch?v=jo_B4LTHi3I
http://socket.io/
David suggested installing MinGW. That didn't fix it, but I did find a different version of libintl-8.dll in the bin folder there.
That one first complained about not having libgcc_s_dw2-1.dll installed, so I had to copy that file over too.
Now, it seems to work.
of Visual Studio.
Still, I can now have a real debug and release mode working in free version of Visual Studio.
Running GDB in terminal mode is going to take some learning, but it's a whole lot better than nothing.
If this debugging can be added in a more integrated way to other free IDE's like
SimpleIDE, CodeBlocks or Eclipse, they will have a big advantage over me in Visual Studio...
(But, I'll stick with it anyway!)
Hello,
Possibly yes, depending on what command is needed to connect GDB
to underlying debugger interface. Typically it is some variant of
"target" command (e.g. "target remote 127.0.0.1:<port>"). If you
enter such command in 'propeller-elf-gdb' then it should work
with WinGDB also. Use Embedded Device mode and enter arguments for
'target' command in "Target specification" field, e.g. "remote 127.0.0.1:<port>".
Best regards,
Przemek Kuczmierczyk
WinGDB.com
Parallax is finishing up a GCC port for their Propeller microcontrollers...
I was looking into using WinGDB with Visual Studio to debugging, but it's not clear it can work...
They are not using a JTAG device, but just a simple USB serial connection over a Windows COM port.
This is how they are set up to debug at the command line:
propeller-elf-gcc -g -o hello.elf hello.c
propeller-load -bc3 hello.elf -r -g
propeller-elf-gdb hello.elf
propeller-elf-gdb then shows a terminal window where the debugging commands can be entered...
Think there's any chance of this working with WinGDB?
Thanks,
Ray
Eric
That doesn't work for SimpleIDE. I have to enter the command in the startup code. Maybe gdbinit would be found if I put it in the propeller-gcc bin ?
Hmmm, that's odd. It's supposed to look for it in $PATH_TO_GDB_PROGRAM/../lib/gdb/gdbinit. Perhaps for some reason argv[0] isn't being set correctly in propeller-elf-gdb. I'm not sure how the runtime picks this up, but perhaps it depends on how you invoke gdb?
Some other alternatives are:
(1) Put a .gdbinit in the $HOME directory (not sure if this will always be set in Windows);
(2) Pass "-x /full/path/to/gdbinit" on the command line when you start propeller-elf-gdb.
Eric
I repeated the simple example above and everything seems OK until I enter "c" for continue.
The response is "The program is not being run.".
I'll have to try on another computer. Maybe somehow I installed something here that messed it up...
Eric
Trying on another PC now... This one gives same message but may have the 26Feb version on it. I'll try again with the 19Mar version...
You must r before you can c.
In other words, set a breakpoint on main, run, wait for (gdb) prompt, then continue.
$ b main
$ r
(gdb) main() ...
$ c