Its just occured to me that if I modularise this debugger then it could be even more useful than just talking to a debug stub on a remote machine. If I have a UDP connection (keeping it as simple as possible), then theres nothing to really stop emulators adding this simple functionality either. Now I've been fed up with emulator debuggers for ages, all ofthem are rubbish and even Minus4's has quite a few issues due to the way I'd initially implemented it. So imagine doing a simple API where you can either write your own comms connection, OR implement a simple Serial/UDP stub on a remote machine or emulator and suddenly everyone could use this as a front end debugger to their own projects.
Now, I susupect it will take some time to get that API correct so it works across so many differnt machines/platforms but in the end it should be kind-of like DevStudio. It can plug into any system and do full debugging on it. As long as the debugger has a CPU plugin (starting with 6502), it can get a query for various high level things like get dissassembly (which could also return a source level view I guess), Step/Trace, Run, Stop, Get/Set Registers, Get/Set Memory, Get/Set breakpoints and all the rest - then it should be possible to make it completely modular.
I'll have to give this some thought as I carry on writing the new version.....
4 comments:
Don't reinvent the wheel with a custom UDP protocol. Just implement the gdb remote protocol over TCP for the best compatibility. It's quite simple, here's an intro.
-Nate
Its an interesting idea, but from first glance its way too much for a small target to implement. I want to have UDP on the C64 as well as emulators, but theres no way Im spending the amount of memory needed for a full gdb stub. Also, if I can get everything I need on a C64 stub then theres probably not much point in adding extra stuff for for an emulator.
That said... I'll look into it more and see whats its likely to cost, or at the very least look a the functions it implements and copy what I need from it as a good starting point.
I want to use as little memory as possible for the stub, and Im currently sitting at around 0.5K (well..421 bytes), but know I have to add some more bits.
The UDP one will take more but it must be less than 1K or its of no use as a professional setup.
(professional in the sense of what I was used to back in the day).
I thought this was a stub built into emulators so you can talk to them from the host computer (or another on the network). If it's an emulator, you don't have to worry as much about space. The gdb protocol is quite small, especially if you implement only part (register access, breakpoints, etc.) I too agree the built-in VICE debugger sucks and would like to have gdb protocol support to plug in whatever I want. Maybe I'll code that up sometime.
If you're doing something on the c64 itself, I agree it needs to be even more small and hard-coded.
Its for both emulators and real machines. Mainly for a real machine I guess, but since Im doing a plug-in system, I figured I could allow emulators access to it as well. But because of that I need to keep it very small. However, its a good refrence to seem what they've used, as chances are I'll need something similar.
Post a Comment