Log in

No account? Create an account
Who debugs the debuggers, part II - http://debedb.livejournal.com as a geek [entries|archive|friends|userinfo]

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Who debugs the debuggers, part II [Oct. 15th, 2005|08:37 pm]

...See also Part I...

The JDB approach is kind of painful. Perhaps, another already existing debugger can be used to try my approach? So far, I am intimidated by Eclipse (or NetBeans), and want something easier. The reason is that at this point my idea of integrating with a debugger is modifying it to supply my own implementation of a Connector - thus, I need the project whose code is easier to beat into an Eclipse project and modify.

As far as more flexible integration with any debugger (for when this project is "mature") that would not require modifying source of the said debuggers, I am considering the following. Since every good debugger has a feature to "attach" to an executing JVM, I will implement a Java-based "tunnel" for JDWP. Looks like GNU Classpath has done all of the annoying work of implementing the spec.

After examining several alternatives, I have decided, for now, to first use modified Trace, and, when that runs out of steam, the Javadt.

I noticed have previously reinvented the wheel when I read about JPDA but did not notice the existence of Trace! In an effort to track down a culprit in an execution of an application, I've replaced the JVM called with FoljersCristals -- my homegrown version of Trace. Do I feel silly now...