I guess propeller-load should be rewritten to use bfd to read elf files rather than including its own elf reader. That way it would probably work with -ggdb3 files as well. Care to take on that project? :-)
It's not the ELF reader, I'm pretty sure. When I do -ggdb3, the symbol for __ccr__ is not found by propeller-elf-nm, either, and since it's an elf file, using the i86 reader to check the names produces the same result. So, if even the normal linux system binutils can't find the symbol -- it's not there.
I tried another idea:
propeller-elf-gcc -g -ggdb3 debug.c -o debug.elf
propeller-elf -r -g debug.elf # This works fine, now.
The symbol now shows up, and the program can be loaded by propeller-load. I've never run into this issue on another system, because generally -ggdb3 would imply -g as well, but apparently not on your version of gcc.... weird. Anyway, no need to redo ELF on the loader, but you might want to document the issue for future reference.
The real problem appears to be that gdbstub, from the SIMPLE-IDE package resets the propeller chip which is why the code isn't there when I look for it...
eg: the program loaded by the propeller-loader goes away when GDB is started ... and whatever gdbstub is using as a monitor program, either one from ROM on the propeller, or one gdbstubs uploads -- takes over after the reset.
Either way: That begs the question as to what kind of kernel is running when GDB initializes the propeller... probably not a very up to date one; is it a Spin debugger -- or an older version of the C kernel ?
In any event, the program $pc is generally aimed at a predictably random place after I use GDB 'load', typically aimed at something called "hub_decode_cmd()"
If I do a continue, the program runs, but the debugging link is trashed and I get a:
error: bad initial response from debug kernel: 49
warning: Remote failure reply: E05
Whether the program is allowed to exit, or I do an infinite loop to prevent it exiting is irrelevant. The Cog never shuts down, for the LEDS that are supposed to light up (that's all debug does, turn on all leds on the cog in main.) don't extinguish. If the cog had been stopped, the outputs would have all gone high impedance.
So, it looks like the debug kernel supplied by simple-ide's gdbstubs is out of date or else, I'm running the program from the wrong start point. So, either I need a to compile a newer gdbstubs, or else -- I need to figure out what the loader is "patching" and do it manually, so that gdb can load the file with the patch in place rather than use the loader, and then figure out what the proper entry point for the code is.
David, I seem to see your name all over the place in the comments for Propeller GCC, so how much of this project did you personally write ! WOW.
Ah, I think I know what's wrong -- if you've mixed a gdbstub from the SimpleIDE release and a gdb from the default branch then that won't work. The gdbstub protocol changed. In fact I don't think gdb ever worked in PropGCC 1.0 (the one in SimpleIDE).
gdb is a bit of a moving target, alas -- I've just pushed changes to build it in the new binutils, but it hasn't been tested much.
The most stable gdb results would probably come from building the sources from the Google Code repository (https://code.google.com/p/propgcc). But if you can stand living on the "bleeding edge" then definitely we could use your help testing gdb in the github repo. I don't think gdbstub has made it over to github in any coherent form yet.I'd actually like to integrate it into gdb itself (it isn't very large) but I haven't had a chance to do that yet.
Ah, I think I know what's wrong -- if you've mixed a gdbstub from the SimpleIDE release and a gdb from the default branch then that won't work. The gdbstub protocol changed. In fact I don't think gdb ever worked in PropGCC 1.0 (the one in SimpleIDE).
gdb is a bit of a moving target, alas -- I've just pushed changes to build it in the new binutils, but it hasn't been tested much.
The most stable gdb results would probably come from building the sources from the Google Code repository (https://code.google.com/p/propgcc). But if you can stand living on the "bleeding edge" then definitely we could use your help testing gdb in the github repo. I don't think gdbstub has made it over to github in any coherent form yet.I'd actually like to integrate it into gdb itself (it isn't very large) but I haven't had a chance to do that yet.
The propgcc git repository in the Parallax github account should be identical to what is in Google Code. We should be using that and not the Google Code version.
Ah, I think I know what's wrong -- if you've mixed a gdbstub from the SimpleIDE release and a gdb from the default branch then that won't work. The gdbstub protocol changed. In fact I don't think gdb ever worked in PropGCC 1.0 (the one in SimpleIDE).
hmm... I'm not quite that crazy...
I used both the gdbstubs and gdb from SimpleIDE as a pair. So, the protocol should match.
eg: Remember, the simple IDE version of gdbstubs is *resetting* the propeller, and causing something to upload.
So --- if it doesn't work, it has to be because the compiled kernel is of a different version and that gets deleted....
Edit: I just figured out that "patching" is just setting the debug bit in the _ccr_ symbol.
But you make a good point, I probably should install SIMPLE_IDE separately on my memory key, and then I can have three scripts to switch between compilers ... use_catalina, use_simpleide, use_propgcc4 ... and install newer gdb stuff with propgcc4.
I just did a clone of the github, and the submodule for gdb didn't show up -- so, yeah, you're right. It's not there yet., as of 3/9/2015
But as it's released in simpleIDE (GPL?), there really should be at least an old repository for an older branch....
To clarify, that link to github is a copy of https://code.google.com/p/propgcc. Since Google Code is getting shut off in the near future, the code was moved out of mercurial and into Parallax's github account.
Here's my experience for any one else wanting to do this... quickly....
I was able to use mercurial, and clone the repository from Google... hopefully that doesn't go away before GDB gets transferred to git.
I see there is a default branch, and the 1.0 release branch, and the prop2 branch....
so, I check out the default as that's clearly the newest of the prop-1 stuff.
But, of course, trying to simply run make didn't work, eg: it bombed out in the libraries.....
and there is no configure script in the top directory... hmm...
So, I tried building the gdb stuff individually and mimmicing the environment I think PropGCC was built in, by
creating a dummy softlink of /parallax to my memory key's actual install of PropGCC-4 tools ....
Then I set my PATH to use the tools in /parallax/bin
To be safe, got rid of old tools...
rm /parallax/bin/gdbstub
rm /parallax/bin/propeller-elf-gdb
Then I went into the gdbstub directory, saw there was no configure script ( ) .... scratched my head
Then I guessed, I would need:
export OS=linux
make
It was happy, and built with no errors no warnings...
cp gdbstub /parallax/bin
cp gdbinit.propeller /media/memoryb1/mysource/.gdbinit # where I test propGCC.
Now, on to GDB. I cleared the OS variable, made a place to build gdb...
cd .. ; mkdir gdb.build ; cd gdb.build
../gdb/configure --prefix=/parallax --host=x86_64-unknown-linux-gnu --target=propeller-elf
make
make install
It chugged away, and built gdb. No more problems.
And of course, I got gdb info pages installed... I hope those are up to date
So, it built -- and it runs --
bash-4.2$ propeller-elf-gcc debug.c -g -ggdb3 -o debug.elf
bash-4.2$ propeller-load -r -g debug.elf
Propeller Version 1 on /dev/ttyUSB0
patching for debug at offset 0x6f8
Loading debug.elf to hub memory
3136 bytes sent
Verifying RAM ... OK
bash-4.2$ propeller-elf-gdb debug.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/>...
Reading symbols from /media/memoryb1/mysource/debug.elf...done.
0x00000048 in start ()
(gdb) break main
Breakpoint 1 at 0x10c: file debug.c, line 3.
(gdb) c
Continuing.
Breakpoint 1, main () at debug.c:3
3 DIRA=0x00FF0000;
(gdb) s
Breakpoint 1, main () at debug.c:3
3 DIRA=0x00FF0000;
(gdb) s
4 OUTA=0x00FF0000;
(gdb) s
5 return 0;
(gdb)
And I am a very happy man, looking at all blue LED's turn on at the appropriate moment. thank you all for your help.
Now I can do what I started this thread to accomlish, eg: port my CNC controller and debug it....
I was able to use mercurial, and clone the repository from Google... hopefully that doesn't go away before GDB gets transferred to git.
The propgcc repository on the Parallax github has everything that Google Code has. It's just my new propeller-gcc repository that is missing gdbstub and I'll move that over this weekend. Eric has already added gdb itself to the binutils build.
Impressive, worthy of an update.
- what size is the GDB stub that resides in the Prop ?
Hmm... everything you wanted to know, and more... depending on how I interpret your question... then the result is detemined by the following comands (with comparison to simple IDE thrown in for fun):
So, it's about a 50K sized binary on an x86-64, i7-4960X linux system. It's a bit larger (~8K) than the original in simple-ide, but probably due to all those bug fixes and additions that allow it to do multi-cog debugging.... and make it actually work?
The source code size for the two directories (as saved on a BTRFS file system) is:
bash-4.2$ du -hc gdbstub gdb | grep -Poe "^\S\s*[^/]*$"
60K gdbstub
150M gdb
150M total
One of these days I need to make a shell alias for that du and grep.... It's nice to be able to get executive summaries for just the info you ask for.
Edit: No time like the present for one liner bash shell additions.
Now I can always find it again here in the threads when I forget how to do it...
The propgcc repository on the Parallax github has everything that Google Code has. It's just my new propeller-gcc repository that is missing gdbstub and I'll move that over this weekend. Eric has already added gdb itself to the binutils build.
Oh boy.... three repositories. at least a server crash can't possibly loose everything now.
A thought occurrs to me about potential future trouble, as gdb is piping output to gdbstub and is supposed to load propeller.gdbinit by default. But neither of those things is auto-path detected by gdb; so -- depending on a user's PATH, a gdbstub from a different version of GDB could accidentally get loaded. Probably, for as long as gdbstub is not part of the GDB binary, it would be a good idea to rename it "propeller-elf-gdbstub" -- and hopefully, someone can make gdb check it's bin install directory if no .gdbinit is found in the user's home directory, or the $PWD directory -- so that by default, it will load the propeller.gdbinit it was compiled with but allow users to over-ride it.
I could figure out how to do that, and post a patch -- if it would help; but i don't know who maintains what, and how I should submit patches for review.
So, it's about a 50K sized binary on an x86-64, i7-4960X linux system.
The source code size for the two directories (as saved on a BTRFS file system) is:
60K gdbstub
150M gdb
Thanks, the info I really wanted may be more hidden - I was after the size impact of the (small?) gdb stub that is patched into the Prop itself, and that may not be directly reported, but maybe a Prop binary size difference of builds with/without gdb enabled will give some idea ? (tho it may not show COGgdb/HUBgdb splits )
Do you know what link-speed the gdb stub uses, & what speed it can go up to ?
gdbstub is a PC side program, so its size has no impact on the Propeller code.
The debug code in the propeller is a kernel extension, so the COG part of it fits in the 256 bytes from 0x6c0 to 0x7c0 (the kernel extension space, into which the kernel loads overlays such as debug, floating point, and integer math). There is a bit of LMM code added as well, but it's merged in to the .hub section so I'm not sure of the exact size.
gdbstub is a PC side program, so its size has no impact on the Propeller code.
The debug code in the propeller is a kernel extension, so the COG part of it fits in the 256 bytes from 0x6c0 to 0x7c0 (the kernel extension space, into which the kernel loads overlays such as debug, floating point, and integer math). There is a bit of LMM code added as well, but it's merged in to the .hub section so I'm not sure of the exact size.
ok, the terminology gdb uses for each piece is new to me.
The kernel extension description suggests that gdb needs LMM mode to run, and cannot work in COG mode, correct ? Or is there a form that can work with COG mode too ?
If it packs into the kernel extension space, does that mean something else has to be excluded ? if so, what is the impact of adding gdb kernel extension to code operation ?
The kernel extension description suggests that gdb needs LMM mode to run, and cannot work in COG mode, correct ?
Correct -- at the moment gdb only works in some LMM derivative form (LMM, CMM, XMM). It relies on changes to the LMM interpreter loop.
If it packs into the kernel extension space, does that mean something else has to be excluded ? if so, what is the impact of adding gdb kernel extension to code operation ?
The kernel extensions are overlays, so nothing else has to be excluded.
Thanks, the info I really wanted may be more hidden - I was after the size impact of the (small?) gdb stub that is patched into the Prop itself, and that may not be directly reported, but maybe a Prop binary size difference of builds with/without gdb enabled will give some idea ? (tho it may not show COGgdb/HUBgdb splits )
Do you know what link-speed the gdb stub uses, & what speed it can go up to ?
Sorry I'm so slow in getting back to you -- I was out of the house for several days...
I think I saw 115200 as the default baud rate in the source code but I would need to untar it again to double check. The device the USB connects to is an FTDI RS232/422 translator chip, so I know that has an absolute max baud rate of about 3Megabaud. but I don't know if the propeller would really keep up with the higher rates, though -- and I'm pretty sure you won't get much better performance, anyway. The COG only has an execution rate of ~16Mips/cog if I recall correctly (80Mhz?), and to do RS232 reliably you can't have jitter more than about 5% in the start bits, so since 3Megabaud is somewhere around 5 instruction times per bit, and even 1 instruction would cause 20% jitter in start time, eg: because the COG transmitting the data is the same one running the C kernel; so basically, I think, the kernel must pause program execution when transmitting or receiving data.
For that reason, I would estimate (and I could be wrong) a max upper limit of around 800kilobaud... but your throughput on average is going to be lower than that -- because there are delays while the kernel loads and stores data in hub ram, and does lookups, and also the FTDI chip pretty much does bauds in binary multiples.
So -- I would hazard a guess that it probably could be pushed to 660800 baud if the software supported it.
OK. That's a GDB debugger on a rasberry PI system.
The PI runs the debugger itself on the system, likely, so that's going to be a *lot* more top-heavy code wise than what's on the Propeller. The code for the propeller doesn't have any TCP/IP stack, linux kernel, or anything on the COG itself -- it's just a very small piece of monitor code that sends memory bytes on demand, in response to a handful of about 5 commands that GDB can send to it; and implents a single breakpoint. The whole thing is pretty small, code wise.
GDB isn't going to be quite as powerful on the Parallax, but you can emualte everything normally done with GDB on an interrupt based processor, by programming GDB to auto-single step the program and implement more than one breakpoint using polling, rather than a simulated hardware interrupt.
Comments
Well that I can help with at least lol
https://github.com/dbetz/propeller-gcc
It's not the ELF reader, I'm pretty sure. When I do -ggdb3, the symbol for __ccr__ is not found by propeller-elf-nm, either, and since it's an elf file, using the i86 reader to check the names produces the same result. So, if even the normal linux system binutils can't find the symbol -- it's not there.
I tried another idea:
propeller-elf-gcc -g -ggdb3 debug.c -o debug.elf
propeller-elf -r -g debug.elf # This works fine, now.
The symbol now shows up, and the program can be loaded by propeller-load. I've never run into this issue on another system, because generally -ggdb3 would imply -g as well, but apparently not on your version of gcc.... weird. Anyway, no need to redo ELF on the loader, but you might want to document the issue for future reference.
The real problem appears to be that gdbstub, from the SIMPLE-IDE package resets the propeller chip which is why the code isn't there when I look for it...
eg: the program loaded by the propeller-loader goes away when GDB is started ... and whatever gdbstub is using as a monitor program, either one from ROM on the propeller, or one gdbstubs uploads -- takes over after the reset.
Either way: That begs the question as to what kind of kernel is running when GDB initializes the propeller... probably not a very up to date one; is it a Spin debugger -- or an older version of the C kernel ?
In any event, the program $pc is generally aimed at a predictably random place after I use GDB 'load', typically aimed at something called "hub_decode_cmd()"
If I do a continue, the program runs, but the debugging link is trashed and I get a:
error: bad initial response from debug kernel: 49
warning: Remote failure reply: E05
Whether the program is allowed to exit, or I do an infinite loop to prevent it exiting is irrelevant. The Cog never shuts down, for the LEDS that are supposed to light up (that's all debug does, turn on all leds on the cog in main.) don't extinguish. If the cog had been stopped, the outputs would have all gone high impedance.
So, it looks like the debug kernel supplied by simple-ide's gdbstubs is out of date or else, I'm running the program from the wrong start point. So, either I need a to compile a newer gdbstubs, or else -- I need to figure out what the loader is "patching" and do it manually, so that gdb can load the file with the patch in place rather than use the loader, and then figure out what the proper entry point for the code is.
David, I seem to see your name all over the place in the comments for Propeller GCC, so how much of this project did you personally write ! WOW.
gdb is a bit of a moving target, alas -- I've just pushed changes to build it in the new binutils, but it hasn't been tested much.
The most stable gdb results would probably come from building the sources from the Google Code repository (https://code.google.com/p/propgcc). But if you can stand living on the "bleeding edge" then definitely we could use your help testing gdb in the github repo. I don't think gdbstub has made it over to github in any coherent form yet.I'd actually like to integrate it into gdb itself (it isn't very large) but I haven't had a chance to do that yet.
hmm... I'm not quite that crazy...
I used both the gdbstubs and gdb from SimpleIDE as a pair. So, the protocol should match.
eg: Remember, the simple IDE version of gdbstubs is *resetting* the propeller, and causing something to upload.
So --- if it doesn't work, it has to be because the compiled kernel is of a different version and that gets deleted....
Edit: I just figured out that "patching" is just setting the debug bit in the _ccr_ symbol.
But you make a good point, I probably should install SIMPLE_IDE separately on my memory key, and then I can have three scripts to switch between compilers ... use_catalina, use_simpleide, use_propgcc4 ... and install newer gdb stuff with propgcc4.
I just did a clone of the github, and the submodule for gdb didn't show up -- so, yeah, you're right. It's not there yet., as of 3/9/2015
But as it's released in simpleIDE (GPL?), there really should be at least an old repository for an older branch....
There is, as David mentioned in the previous post. Guess he forgot the link though :P
https://github.com/parallaxinc/propgcc
To clarify, that link to github is a copy of https://code.google.com/p/propgcc. Since Google Code is getting shut off in the near future, the code was moved out of mercurial and into Parallax's github account.
Here's my experience for any one else wanting to do this... quickly....
I was able to use mercurial, and clone the repository from Google... hopefully that doesn't go away before GDB gets transferred to git.
I see there is a default branch, and the 1.0 release branch, and the prop2 branch....
so, I check out the default as that's clearly the newest of the prop-1 stuff.
But, of course, trying to simply run make didn't work, eg: it bombed out in the libraries.....
and there is no configure script in the top directory... hmm...
So, I tried building the gdb stuff individually and mimmicing the environment I think PropGCC was built in, by
creating a dummy softlink of /parallax to my memory key's actual install of PropGCC-4 tools ....
Then I set my PATH to use the tools in /parallax/bin
To be safe, got rid of old tools...
rm /parallax/bin/gdbstub
rm /parallax/bin/propeller-elf-gdb
Then I went into the gdbstub directory, saw there was no configure script (
Then I guessed, I would need:
export OS=linux
make
It was happy, and built with no errors no warnings...
cp gdbstub /parallax/bin
cp gdbinit.propeller /media/memoryb1/mysource/.gdbinit # where I test propGCC.
Now, on to GDB. I cleared the OS variable, made a place to build gdb...
cd .. ; mkdir gdb.build ; cd gdb.build
../gdb/configure --prefix=/parallax --host=x86_64-unknown-linux-gnu --target=propeller-elf
make
make install
It chugged away, and built gdb. No more problems.
And of course, I got gdb info pages installed... I hope those are up to date
So, it built -- and it runs --
And I am a very happy man, looking at all blue LED's turn on at the appropriate moment.
Now I can do what I started this thread to accomlish, eg: port my CNC controller and debug it....
- what size is the GDB stub that resides in the Prop ?
Hmm... everything you wanted to know, and more... depending on how I interpret your question... then the result is detemined by the following comands (with comparison to simple IDE thrown in for fun):
So, it's about a 50K sized binary on an x86-64, i7-4960X linux system. It's a bit larger (~8K) than the original in simple-ide, but probably due to all those bug fixes and additions that allow it to do multi-cog debugging.... and make it actually work?
The source code size for the two directories (as saved on a BTRFS file system) is:
One of these days I need to make a shell alias for that du and grep.... It's nice to be able to get executive summaries for just the info you ask for.
Edit: No time like the present for one liner bash shell additions.
Now I can always find it again here in the threads when I forget how to do it...
echo "duExecutive() { \du -hc ${*} | grep -Poe '^\S*\s*[^/]*$' ; } ; alias du='duExecutive'" >> ~/.bashrcOh boy.... three repositories.
A thought occurrs to me about potential future trouble, as gdb is piping output to gdbstub and is supposed to load propeller.gdbinit by default. But neither of those things is auto-path detected by gdb; so -- depending on a user's PATH, a gdbstub from a different version of GDB could accidentally get loaded. Probably, for as long as gdbstub is not part of the GDB binary, it would be a good idea to rename it "propeller-elf-gdbstub" -- and hopefully, someone can make gdb check it's bin install directory if no .gdbinit is found in the user's home directory, or the $PWD directory -- so that by default, it will load the propeller.gdbinit it was compiled with but allow users to over-ride it.
I could figure out how to do that, and post a patch -- if it would help; but i don't know who maintains what, and how I should submit patches for review.
Do you know what link-speed the gdb stub uses, & what speed it can go up to ?
Also, can you run your 'gdb expert eye' over this thread
http://forum.lazarus.freepascal.org/index.php?topic=20101.0
and comment on how close that may be to what you have got working ?
The debug code in the propeller is a kernel extension, so the COG part of it fits in the 256 bytes from 0x6c0 to 0x7c0 (the kernel extension space, into which the kernel loads overlays such as debug, floating point, and integer math). There is a bit of LMM code added as well, but it's merged in to the .hub section so I'm not sure of the exact size.
The kernel extension description suggests that gdb needs LMM mode to run, and cannot work in COG mode, correct ? Or is there a form that can work with COG mode too ?
If it packs into the kernel extension space, does that mean something else has to be excluded ? if so, what is the impact of adding gdb kernel extension to code operation ?
Sorry I'm so slow in getting back to you -- I was out of the house for several days...
I think I saw 115200 as the default baud rate in the source code but I would need to untar it again to double check. The device the USB connects to is an FTDI RS232/422 translator chip, so I know that has an absolute max baud rate of about 3Megabaud. but I don't know if the propeller would really keep up with the higher rates, though -- and I'm pretty sure you won't get much better performance, anyway. The COG only has an execution rate of ~16Mips/cog if I recall correctly (80Mhz?), and to do RS232 reliably you can't have jitter more than about 5% in the start bits, so since 3Megabaud is somewhere around 5 instruction times per bit, and even 1 instruction would cause 20% jitter in start time, eg: because the COG transmitting the data is the same one running the C kernel; so basically, I think, the kernel must pause program execution when transmitting or receiving data.
For that reason, I would estimate (and I could be wrong) a max upper limit of around 800kilobaud... but your throughput on average is going to be lower than that -- because there are delays while the kernel loads and stores data in hub ram, and does lookups, and also the FTDI chip pretty much does bauds in binary multiples.
So -- I would hazard a guess that it probably could be pushed to 660800 baud if the software supported it.
OK. That's a GDB debugger on a rasberry PI system.
The PI runs the debugger itself on the system, likely, so that's going to be a *lot* more top-heavy code wise than what's on the Propeller. The code for the propeller doesn't have any TCP/IP stack, linux kernel, or anything on the COG itself -- it's just a very small piece of monitor code that sends memory bytes on demand, in response to a handful of about 5 commands that GDB can send to it; and implents a single breakpoint. The whole thing is pretty small, code wise.
GDB isn't going to be quite as powerful on the Parallax, but you can emualte everything normally done with GDB on an interrupt based processor, by programming GDB to auto-single step the program and implement more than one breakpoint using polling, rather than a simulated hardware interrupt.