almost seamless, need tests and interest !

Since my last post on my google summer of code project, I am proud to announce great advancements.
First of all, I find how to have the C/C++ file editor. I use org.eclipse.cdt.debug.core.sourcePathComputer instead of my JMLSourcePathComputer and it works fine ! (I can't explain why it does not work with my JMLSourcePathComputer, if someone knows I am interested)

Then I automated the resume on the JVM thread. You does need anymore to do it manually (the seventh step in the previous post).

Then I implemented the automatic breakpoints addition on C/C++ native functions. To do that I rely on the CDT possibilies and the JNICALL magic keyword. You does need anymore to do it manually (the fourth step in the previous post )

And finally I am working now on the debug events, in order that when the user choose to step over a Java native call, the C breakpoints are automatically resumed. It works well for the moment from Java to C/C++ native code, but I still have to work for the other direction (C/C++ code which calls Java methods).

The next step will be to provide some JUnit tests

I hope the eclipse community will found interest in this work, and help me to improve and test this plug-in.
I am sure this functionnality will be helpfull for some people, so if you have some free hours, test it, read/review the code, or comment this post.
Thanks !

other change since the last time

• java version min: 1.4

• bugzilla : there is org.eclipse.soc.jni component in eclipse bugzilla

problems known

• sometimes gdb does not success to attach to the pid. I don't know why. Not regular and seems to be a gdb bug or limitation.
• the automatic breakpoints addition does not check if previous breakpoints were added at the same line. Will be resolved soon.
  

Project status

Work done

• Creation of a new plug-in : the plug-in adds a "JNI Application" group in the "Debug Dialog"

• When we launch a debug session :

• The JVM is lauched and Java internal debugger of Eclipse connects to it

• The PID of the lauched JVM is found

• The C debugger is attached to the launched JVM process (it works with gdb, I dont know if others debuggers offer this possibility )

• The debug perspective is open and we could see the 2 debuggers launched

Cookbook

versions used : eclipse SDK 3.3 RC4 and CDT 4.0 RC3
os : GNU/linux on a ppc processor
java version min: 1.5 (I think I will change to 1.4)


getting the svn code : svn co https://eclipse-incub.svn.sourceforge.net/svnroot/eclipse-incub/jni_seamless_debugging jni_seamless_debugging

• First step : you have to install the plugin. If you are here, I am sure you know how to do it.

• Second step : you have to create a Java Application which uses JNI.

• Third step : set a breakpoint in the Java code after the code which loads the native library
  
  
  
  

• Fourth step : set a breakpoint in the C code in the begin of a native method
  
  
  
  

• Fifth step : Open the debug dialog and create a new configuration of "Java JNI Application" kind
  
  
  In the tabs you have to configure the Java and C project, and specify the javaw path as C/C++ application. On linux machines you could have to add the current directory in the library path environment variable
  
  
  
  
  Then click on debug
• Sixth step : the debug perspective will be launched, with the 2 debuggers.
  
  
  
  
• Seventh step : Resume the JVM process (right click on "gdb/mi") and start debugging !
  
  

Problems

It makes 3 weeks that I am working on C source files visualisation. I spend too much time on this, and don't find why it doesn't work.

To resume :

• I have created a JMLSourceLookupDirector

• I have added CParticipant and JavaParticipant

• I have created a JMLSourcePathComputer which contains a JavaSourcePathComputer and a CDelegate.For the computeSourceContainers() method I only merge results obtained from JavaSourcePathComputer and CDelegate computeSourceContainers() methods. I checked with the debugger, and it works well.
  

When I try to debug a JNI Application with my plug-in, the JVM is launched, gdb is attached and the code stop on the first breakpoint in the Java Code. Then I debug step by step until the native call.
When I arrive to the breakpoint in the C code, it stops well, but the Editor doesn't display the file.



Of course the path is correct and the directory is in the source path.

Any idea or comment is welcome

An approach I want to try

After I had read the presentation from presenting a way to debug JNI application in Eclipse (see last post for the link), I think that an approach to provide Seamless debugging between JDT and CDT could be the following :

• Step 0 : the user sets its breakpoints in Java Code and in C code
• Step 1 : we launch app for remote java code debugging
• Step 2 : we attach gdb to the application's Java VM with process ID and resume ("release" the JVM) and set " C user breakpoints"
• Step 3 : we set "default breakpoints" in C/C++ code on each native method called by java code
• Step 4: we attach jdb
• Step 5: ready to go !
• Step 6 : Java breakpoint is hit first. The user steps over until the native call :

- he decides to step into : The default breakpoint is hit in gdb. The user then decides what to do
- he decides to step over : The default breakpoint is hit, but CDI sends a "continue" to the debugger

To proof that is a possible way, I currently a writing a prototype plugin, based on JDT and CDT plugins, which (at this time) uses the following extension :

• org.eclipse.debug.core.lauchConfigurationTypes
• org.eclipse.debug.ui.lauchConfigurationTabGroups
• org.eclipse.debug.ui.lauchConfigurationTypeImages

The main difficulty seems to be the retrieval of the JVM process ID, but I got (Thanks to Mattew) this useful link http://net3x.blogspot.com/2007/03/how-java-application-can-discover-its.html with differents ways to get the PID.

Feel free to comment this approach.

Follow the white rabbit..

I begin my summer of code by getting in touch with Eclipse community and other gsoc students working on Eclipse projet. During these first weeks I read documentation on the Eclipse framework and some tutorials. I sent an email to CDT-dev mailing list to announce the project and to get feedback and some pointers. Thanks to a response I found an interesting presentation from Intel's guys, who propose a new debug interface for mixed applications, XDI (eXtensible Debug Interface), in remplacement of the current JDI (Java Debug Interface). In the document they present several approaches to provide mixed mode debugging in Eclipse with advantages and problems for each approach. However XDI is not yet standardized and requires an XDI agent implementation in the JRE.
My mentor gave me too some links on existing work. One presentation explains how to debug JNI application currently with Eclipse. It's not so easy but it's possible. As I see currently see it, my job will consist in automating that so that becomes seamless and more powerfull.
I hope to succeed, it will be really nice to have this feature in Eclipse.