Here’s a rough outline of my Mojo debugger Eclipse Plugin. This is a work in progress.
The packages in yellow are where I am hooking into the Palm jars from the SDK. Note the states defined in bottom right. The controller issues commands to the connected emulator and the current state processes the response.
I haven’t filled in all the methods or classes quite yet as the design is in a state of flux.
My next task is to add a kindof blocking queue which the debug target will attach to when the UI requests debug info. This will block (with timeout) for data such as the stack trace and the local variables. The current state will populate a central debug resource, as it is reads back data from the terminal stream, and signal to the queue when data is available. That’s my current idea for the moment anyway.
I have the pause working with displaying the stack frame. It’s a bit fragile. The acid test is can I get the breakpoint support working? No screen shots as I don’t want to build anyones hopes up. Unbelievably this was the easy bit and it’s only taken me a few weeks (sarcasm) to get to.
I assume Palm are working on this as well and since they can alter the debugger as they see fit I suppose this is a bit of a non-runner (at least for now). I should say that this is just a ‘lunchtime’ project and I am only spending about an hour a day on it. We’ll see how it goes. I am confused about the debugger being GDB compatible. If that’s the case then maybe I am wasting my time. It’s fun anyway as a learning process.
My internet connection is back up!
I have started to rewrite the state machine as it was too unwieldy. The states now encapsulate the outgoing request and the response rather than put that burden on the controller. Having re-factored it the whole thing makes better sense now and flows better. Not finished yet though, still a ways to go.
There is an update to the IFrame. RAB and KAM (many thanks) have posted there update here. This will make it’s way into the main source update really soon I promise. It’s remiss of me to update this stuff but life has intervened.
As mentioned in the previous post I had a look at the WebOS SDK and was mightily dissapointed that Palm hadn’t bothered to hook the debugger into the Eclipse plugin. Well I though it might be an interesting project to try and write a debugger front-end.
I started off looking at the ports from the emulator and trying to capture the commands that go between the two using WireShark. No luck, not sure why but it seems that it can’t capture stuff between the virtual network link and the host PC. Fair enough. I then looked into their jar files that compose the Palm plugin and realised that I could call their API to do the same thing. So, I recreated their plugin. This wasn’t easy..
Writing an Eclipse plugin is a bit of a dark art. It’s one of those thing that most programmers don’t have to do. So far I have the following working:
- Launching an application.
- Terminating an application.
- Launching the debugger.
- Talking to the debugger to start and stop the application.
- State machine for processing debugger output.
- Capture break condition to extract method, line and column numbers.
- UI reflecting pause status correctly.
- Eclipse shutdown pulling down any application launched from Eclipse plugin.
Talking to the emulator requires the use of methods from the Palm JARs bundled with the SDK. The API lets me open a TTY terminal connection to the emulator. I am querying if there is an existing debug process and if not it will start one up. At that point we can control the debugger and get output back from it.
The response is processed depending on the current ‘state’. The state is set by the operations from the user (break, run etc) and a state machine transitions around to capture the output and process it accordingly.