DIY ImageCraft C Debugger...
ImageCraft
Posts: 348
As I said in my blog, one thing about the Propeller forum is that there are a lot of smart people here. Whatnot with people working on JVM, PBASIC, and now DIY C, well, frankly, I am jealous. I mean, if I have someone like "yppih" (not the true handle) hacking code for me, Propeller C would have been released 6 months earlier with complete floating point support etc. As is, poor Steve is producing C libs like clockwork. So I gather that the Propeller community seems to value hacking (in the pre-90s sense of the word). Well, hacking for ICC is different from doing things in the context of open source / MIT-license type of thing because, well, ICC is not Open Source. But if you don't mind that and are looking for a "challenge," here's something to chew on:
All the debugging support is already there for a source level debugger.
****
First the debug info. It happens that we support both ELF format, and more importantly, a simple ASCII format debug output. This is already active. Build a project under ICC and in the output directory, there is a file with the .DBG extension. The content looks something like:
DIR ./
FILE cmpzero.c
FUNC main 878 I
BLOCK 19 878
LINE 19 878
LINE 20 87c
...
LINE 57 1048
BLOCKEND 57 1064
FUNCEND 1064
FILE cmpzero.c
DEFGLOBAL tab 1a40 A[noparse][[/noparse]3:3]I
DEFGLOBAL tabl 1a4c A[noparse][[/noparse]3:3]L
...
The "LINE" directive tells you how to correlate line numbers to program addresses. DEFGLOBAL (and other DEF...s) tell you the names, types and locations of variables and so on. Pretty much everything describing the C program is there.
****
How to insert a breakpoint
This is where the LMM kernel comes in handy. We just need to temporarily replace the instruction with a "jump to debug kernel routine" instruction. The current kernel already has space reserved for the debug support.
****
So how does it work?
A debug Cog (or likely, portion of the C LIB Cog) serves as a bridge between the PC debugger software and the other Cogs running user program. The debug Cog uses the high speed serial link and listens for the "breakpoint" debug command from the PC. When it gets one, it replaces the program instruction with the "jump to debug" call, and waits for the instruction to get executed.
When the debug kernel routine takes control, it will use the debug Cog to communicate with the PC debugger. The minimal set of commands need to support a debugger is actually pretty small, in the order of:
- Read or write a Hub memory location
- Read or write a Cog memory location
- Read or write machine registers (which are just Cog memory locations in this case)
- delete the breakpoint
- resume execution
Pretty much everything can be built on top of these and the breakpoint instruction. Single stepping? Just repeatedly replace the instruction at the next virtual PC and go. Of course nothing preventing us from adding a single stepping command.
The number of breakpoint is only limited by how much memory we want to devote to it, making it more flexible than most systems.
****
That PC Debugger...
If you are adventurous, you can write a full blown GUI debugger. Or may be a simple line oriented one. Or you can even adapt GDB or the like.
Our official plan? http://www.noicedebugger.com is the 3rd party debugger that we have cooperated with for over 10 years. My hope is that I can convince them to join us in supporting the Propeller. We shall see.
With our planned "Next Gen IDE" in the form of the Visual Studio 2008 Add On, there is a possibility of integrating a debugger into the IDE. This would definitely be a goal for that project, but no concrete plan yet.
****
So there you have it. May be no one will take up the challenge (until we have the resources to do it ourselves), but at least the information is out here...
// richard
All the debugging support is already there for a source level debugger.
****
First the debug info. It happens that we support both ELF format, and more importantly, a simple ASCII format debug output. This is already active. Build a project under ICC and in the output directory, there is a file with the .DBG extension. The content looks something like:
DIR ./
FILE cmpzero.c
FUNC main 878 I
BLOCK 19 878
LINE 19 878
LINE 20 87c
...
LINE 57 1048
BLOCKEND 57 1064
FUNCEND 1064
FILE cmpzero.c
DEFGLOBAL tab 1a40 A[noparse][[/noparse]3:3]I
DEFGLOBAL tabl 1a4c A[noparse][[/noparse]3:3]L
...
The "LINE" directive tells you how to correlate line numbers to program addresses. DEFGLOBAL (and other DEF...s) tell you the names, types and locations of variables and so on. Pretty much everything describing the C program is there.
****
How to insert a breakpoint
This is where the LMM kernel comes in handy. We just need to temporarily replace the instruction with a "jump to debug kernel routine" instruction. The current kernel already has space reserved for the debug support.
****
So how does it work?
A debug Cog (or likely, portion of the C LIB Cog) serves as a bridge between the PC debugger software and the other Cogs running user program. The debug Cog uses the high speed serial link and listens for the "breakpoint" debug command from the PC. When it gets one, it replaces the program instruction with the "jump to debug" call, and waits for the instruction to get executed.
When the debug kernel routine takes control, it will use the debug Cog to communicate with the PC debugger. The minimal set of commands need to support a debugger is actually pretty small, in the order of:
- Read or write a Hub memory location
- Read or write a Cog memory location
- Read or write machine registers (which are just Cog memory locations in this case)
- delete the breakpoint
- resume execution
Pretty much everything can be built on top of these and the breakpoint instruction. Single stepping? Just repeatedly replace the instruction at the next virtual PC and go. Of course nothing preventing us from adding a single stepping command.
The number of breakpoint is only limited by how much memory we want to devote to it, making it more flexible than most systems.
****
That PC Debugger...
If you are adventurous, you can write a full blown GUI debugger. Or may be a simple line oriented one. Or you can even adapt GDB or the like.
Our official plan? http://www.noicedebugger.com is the 3rd party debugger that we have cooperated with for over 10 years. My hope is that I can convince them to join us in supporting the Propeller. We shall see.
With our planned "Next Gen IDE" in the form of the Visual Studio 2008 Add On, there is a possibility of integrating a debugger into the IDE. This would definitely be a goal for that project, but no concrete plan yet.
****
So there you have it. May be no one will take up the challenge (until we have the resources to do it ourselves), but at least the information is out here...
// richard
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
My debugging for spin and asm has a somewhat similar approach. It just single steps continuously using FDX, executing asm instructions in hub (doesn't replace the cog instruction). Only uses 8 longs in cog.
I am sure the PC debugger that suits your code would be able to suit mine as well - that would make a really useful debugger (c, spin and asm). Hippy has done the spin decoder (PropView)
I also love the concept of the "Net Gen IDE".
It's pretty clear the LMM kernel will have to do some trapping. I've worked with LMM kernel "interrupts" before and a similar approach can be used with this. Virtual interrupts using LMM?·describes how to do LMM kernel interrupt handlers with a working example.
I'm still trying to finish something else otherwise I would just do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
1) Debugging support in-chip ( within the LMM kernel plus support code )
2) A PC side application to control the LMM Kernel and do the debugging
3) The protocol between the two
Get (3) right and that creates a lot of flexibility, choice of PC debugger and ability to use the debugger with non-C code as well.
For (1), simplest is best IMO. Should have minimal footprint but support single step and report back all 512 longs of Cog, a means to read/write any Cog/Hub memory location, a means to execute to any breakpoint. The PC side can do the setting / replacement of breakpoint instructions so the kernel doesn't have to worry about any of that, just support the primitives. Much like Richard say.
The kernel needs a hook to stop or continue at every instruction Fetch/Execute and a call handler into it to dump its Cog contents to Hub memory, set a flag and wait for a command before continuing, other commands can read/write Cog memory. The rest of the complexity is in another Cog which interfaces between the Cog/PC using the shared memory it and the Cog communicates through.
This is how I've done my LMM debugging but using TV and without a link to PC. That Cog ( probably running Spin ) can use bit-banged serial to save another Cog but limits the speed.
For (2), that can be as complex or as simplistic as one wants, as long as it supports (3), the protocol. It doesn't need to support all the protocol, just enough to do the job.
That is a well-thought plan of attack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH - Electronics: Engineer - Programming: Professional
I am going to post my debug code for pasm this afternoon (wherever it is up to - I am away over the weekend and I think the opportunity to share outweighs the desire to complete it before posting). It is not working but shows the concept that I am using. It can do anything really, just by changing the hub LMM code. I have already posted the spin debug code, which uses the same concept but it was a little more primitive and required fixed addresses (unallocated) in hub. As it was originally only conceived for my use only, this was quicker. Now I realise its potential - after seeing your propview disassembler. I know that the code can be anywhere with just a bit of extra work on my part. The asm version will do just that (tbd but I know how to).
The debug code must be simple, flexible, and easy to add to the users code. Mine·requires·8 longs of nops at the start of the user code which will be updated by the debugger while the user code is still resident in hub memory. All debug code is contained in a seperate object so it can be updated as a whole without requiring any more changes to the users code. Full control of the cog is maintained by the debug routine, so dumping of cog and hub is easy in the debug object under control of the pc (or whatever).
So I guess your item 3 becomes more important than ever to have a real pc debugger common to C, basic, forth,·spin, asm and anything else that comes along.
What with·these threads, Chips thread, and the sqrt thread, my heads a-buzzing
Now, if only time would help, so I can complete these projects·
[code]
!
?
caddr
Csig;addr
D
FRC,EE,CF;XX
g
GXXI