Do you mean gdb (debugger)? If so, it should be possible, and I was looking at it a while ago (with the USB<->Link cable), but I never got around to really digging into getting it to work. It’s not really high on my priority list right now, but when I get some time I might look into it again. I know David Tucker was very interested in adding gdb support, but I think he’s really busy, so I wouldn’t count on him getting it done soon either.
Yeah, I did a very simple debugger where I had the link interrupt handled with a debugging ISR so I could send a command over the link cable, it’d interrupt the program and either read/write memory, registers, etc. It didn’t have a good interface though (just a command line app that’d ask for the command, ask for the address/reg, then ask for the value to write, or length to read). It worked, and if gdb wasn’t going to be possible I was gonna write my own simple debugger that imports the memory map so you could watch variables and things, but I dropped that idea when I talked to David Tucker and he suggested gdb wouldn’t be too difficult. I figured there’s no point in spending time going to a non-standard and fairly limited debugger when I could instead spend the time to make a backend for gdb and we’d have a really good debugger (with some good available frontends).
The biggest limitation that I came across was that we don’t have a good way to do breakpoints. There’s a TRAP register, which will allow a single breakpoint, but if you want several breakpoints, that’s very difficult because we don’t have either hardware to watch the memory busses and halt on a certain address, or for a software solution we can replace code at a certain address with a jump to our debugging handler which will halt the execution… except with a flash cart, to rewrite a single instruction we need to erase the block, and rewrite the entire block with the modified code. That’s a little time consuming for just a simple operation (probably ~1-2 seconds each time you set or clear a breakpoint)… although it is doable. It’d be much nicer with an SRAM cart (which I’m almost considering building, since that’d be really quick for programming as well).
Well even having just 1 breakpoint, and being able to make a trace from there would be ages ahead of what we have to do now (program blindly), and about the 1-2 seconds delay.. well it maybe takes me 10-20 to change a print instruction, compile again and reach the problem execution point, so I don’t think that will bother me.
I’m not sure about an actual profiler, but you should be able to profile your own code by setting the timer and checking the difference between entry and exit of the function (and storing it in an array somewhere that you can view).
