End of gsoc : the show must go on !

Today is the end of google summer of code 2007 edition.
First I would like to thank Philippe and mentors from Eclipse, the others students (check their projects, they achieved great results !), and google of course.
Thanks also to people who followed and commented this irregular diary of my work :).
I would, too, to provide some feedback. From a student point of view, it was a awesome experience ! I learned a lot, both technical skills and communication skills. Eclipse is divided in a large number of projects, and thus a continuing source of knowledge, for people people "curious" like me.
About what gsoc brings to eclipse, I think it helps to integrate students into the eclipse community, and that a point where in my opinion some progress can be made. For instance I remarked that for the next eclipse summit there is no "registration fees" or invitation for students.

I know there is some reflection, and I think that is the good way.

If you are interested to hear another gsoc feedback, I recommend to you the podcast of Philippe answering questions from Leslie Hawtorne of google.

Regarding my plug-in I will provide soon new screencasts with some comments, and detail what are the next plans.

Jni plug-in in action : Screencasts part. 1

The end of google summer of code is near and before the end I wished to provide some screencasts of the plug-in I created for this time. The five screencasts are in order :

• starting a Jni debug session



• step into native code



• step into java code from native code



• go back in native code



• go back in java code

Thanks to the guy who wrote recordmydesktop software. It is the perfect tool to create screencasts.

project status, version 0.0.2 is available

The plug-in to improve debugging of Java Jni Application is available in a new version : 0.0.2
Improvements since the last version :

• Code to follow call of java methods from native code completely rewritten. The plug-in does not rely anymore on the ending lines of native functions. Less code and more reliable !
• Correction of some bugs and creation of message dialogs instead of using standard output stream.
  

• Documentation on the eclipse wiki page and advertisement on eclipse mailing lists

Some links :

• How to install the plug-in
  
• How to use the plug-in
  
• How to report a bug/ask for an enhancement
  

Eclipse tip : How to get the current debug file ?

I think its trivial for a lot of people but I have been searching for a long time in google before to found how to do it. I suppose you have the current debug thread (for instance from a debug event).

the bad way (does not work):

PlatformUI.getWorkbench().getDisplay().syncExec(new Runnable() {
public void run() {
IEditorPart ed = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage().getActiveEditor();
if (ed.getEditorInput() instanceof IFileEditorInput) {
String currentDebugFile = ((IFileEditorInput)ed.getEditorInput()).getFile().getLocation().toOSString();
}
}
});

the correct way :

Object o = thread.getLaunch().getSourceLocator().getSourceElement(thread.getTopStackFrame());
if (o instanceof IFile) {
String currentDebugFile = ((IFile) o).getLocation().toOSString();
}

project status, first version of plug-in to improve the Java/JNI applications debugging to download

Since my previous post (already tree weeks) I am working hard to have some results. The problem with the breakpoints automatically added is now resolved, and the support to step from C native code to Java code implemented. This support was not so easy to add as I first thinked. Before more explanation, to not lost courageous reader of this post, I think its necessary to remind the solution I choose to step from java code into C/C++ native code.

I decided to automaticaly add a breakpoint on the first line of each native method susceptible to be called by java code. When the user selects the debug action on a native method in Java code, the plug-in stores this action. Then the C/C++ debugger reaches the breakpoint. If the last action was stepping over or return, the plug-in does a step return otherwise it does nothing.

This approach was not a good option in my point of view to follow call of Java methods from C/C++ code due to the high number of java classes (and so methods) generally present in a project. More over breakpoints are not really required, the JDT debugger will stop itself when we reach java code. The problem was to know in which case we are : Did the current C/C++ function call a java method or is the C/C++ function already terminated ?

The solution I chose is to rely on the line number of the ending line of a native function. When it is reached , the plug-in supposes that we are no more stepping in native code. I don't know if it is the best solution. Another option is to rely on the line number of the java native call.

You can install the plug-in by adding the following remote site to the Eclipse update manager : http://eclipse-incub.svn.sourceforge.net/viewvc/*checkout*/eclipse-incub/jni_seamless_debugging/update-site/site.xml

To reports bugs/enhancement there is a "org.eclipse.soc.jni" component in SOC (which is in Technology category)

To use the plugin please refer to previous posts. I will add documentation on the wiki page as soon as possible.

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 java files not directly in the the project do not display (see bug #198804)
  

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.