Recently I've got a chance to talk with several commercial VM engineer, and I would like to publish some summary of conversation:
- "I use Visual studio for native and Eclipse for java"
- "I would really like to be able to debug by going from JVM-code to Java-code and back"
- That would be more interesting if it would be more VM-independent
- "It is a bit scary to expect the jvm that you debug, be responsible for future debugging"
- "It would be interesting/fun to implement it in XXX as well"
Also I've chance to talk with author Mariot Chauvin of gdb-centric solution (see [http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/presentations/spring2006/debugger_for_eclipse.ppt?cvsroot=Tools_Project]
for details). He's mentioned about some instability of gdb/MI + Eclipse, and think that in VM debugging could add some stability.
Some my comment and thoughts.
First of all great thank to anonymous VM engineer and Mariot for interesting feedbacks and ideas. As for me I agree with instability GDB/MI, so why personally I prefer GDB/CLI. I agree with Mariot about "unmodified debugger"-centric solution, especially that the most modern VM doesn't use C-calling convention in jitted code and there should be some "extension" like CDB ("Microsoft Debugging Tools for Windows") has got to handle method entry/exit and JNI up(down)call to help debugger, mixing stacks and stack walking.
With NCAI we has the most issues resolved (java stack handling, jvmti safe points and other java world related things).