Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-debug-dev] Debugger improvement ideas/ wish list
Hi Doug,

Thank you for your interest. I apologize for the delay of this response, I wanted to have some new infos from my last email .
> So according to your blog, you're at the stage now where you have to set breakpoints on
> the Java and C sides of a JNI call, correct?  I assume seamless stepping through the JNI
> call is something you'll be working on next? 

Since few days ago, a first version in available to download (0.0.1). Concretely this version add an entry in the Debug dialog, which allow you to launch a JNI debug session. After creating a new configuration with the correct setting, if you launch it, the JVM will be launched and gdb attached to its pid and the two targets will be displayed.

Then you can follow the call of native functions into native code. For instance, regarding this Java line :

new JNITest().native_doubleInt(42);

if you choose to step into, then you will go into native code :

JNIEXPORT jint JNICALL Java_JNITest_native_1doubleInt (JNIEnv *pEnv, jobject  obj, jint  value) {

if you choose to step over, or step return, you will simply go on the next Java code line.

The same behavior is available to follow java call from native code. For instance regarding this C line :

(*pEnv)->CallVoidMethod(pEnv,obj,mid);

if you choose to step into, then you will go into the java method. Otherwise if you choose to step over, or step return, you will simply go on the next native code line.

To use it please refer to posts on  : http://eclipse-soc-mariot.blogspot.com
More documentation will be soon available on the following wiki page : http://wiki.eclipse.org/index.php/Support_seamless_debugging_between_JDT_and_CDT

to install it an update site is available : http://eclipse-incub.svn.sourceforge.net/viewvc/*checkout*/eclipse-incub/jni_seamless_debugging/update-site/site.xml

As it is the first version, you will surely find a lot of bugs/problems, please report them on the eclipse bugzilla. There is a " org.eclipse.soc.jni" component in SOC which is in Technology category (please add me in CC).

I will appreciate any feedback to improve this plugin.

> We've done commercial work to implement this, but we'd much rather have an open
> source solution, so we're glad to hear you're working on it.  At some point when you're
> ready, a couple of folks on my team will want to talk to you about your implementation.

I am too for an open-source solution, and I am sure your work on this feature will help. Let them feel free to contact me.

Regards,

Mariot

--
Mariot Chauvin

2007/7/24, Gaff, Doug <doug.gaff@xxxxxxxxxxxxx>:

Thanks for the link Mariot.

 

So according to your blog, you're at the stage now where you have to set breakpoints on the Java and C sides of a JNI call, correct?  I assume seamless stepping through the JNI call is something you'll be working on next? 

 

We've done commercial work to implement this, but we'd much rather have an open source solution, so we're glad to hear you're working on it.  At some point when you're ready, a couple of folks on my team will want to talk to you about your implementation.

 

Doug Gaff

 

From: platform-debug-dev-bounces@xxxxxxxxxxx [mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Mariot Chauvin
Sent: Tuesday, July 24, 2007 3:15 AM
To: Eclipse Platform Debug component developers list.
Subject: Re: [platform-debug-dev] Debugger improvement ideas/ wish list

 

>*Truly integrated Java/C debugging

> By truly integrated, I mean I imagine stepping into a JNI call in java and seamlessly transitioning to C debugging.  
> By seamlessly, I mean: the Debug view should have a single debug target, which is showing a stack trace with both >java and C stack frames.  I think the only way we'll achieve this kind of integration is by writing UI layer which is >reading data from both the Java and C debuggers, which I imagine this would be a lot easier to do if the java >debugger was implemented using the DSF services framework.

Hi all,

Just to point that in the scope of the google summer of code for the Eclipse project, I am currently writing a plug-in to provide seamless Java/JNI/C debugging. More information could be found on http://eclipse-soc-mariot.blogspot.com.

Regards,

Mariot

2007/7/23, Pawel Piech < pawel.piech@xxxxxxxxxxxxx>:

Hi All,
Doug Gaff asked me to follow up after the recent Platform Debug team committer diversity discussion with a general list of tasks that Wind River would like to work on in the Platform.  Here is the list we came up with. 

I put a star in front of items that would probably involve platform changes.

-Pawel

P.S. I wrote this up before writing up the multi-context debugging ideas email, so there may be some repetition here.

Embedded/Remote debugging

Better Integration with Target Manager

This is probably more of a TM task but it's also part of an over-all debugger experience:

  • Ability to drive debugger views from within TM
    • Create a GDB debugger sub-system to configure GDB and to manage GDB sessions.
  • Standard launch dialog pages for configuring TM.
    • Configure new targets and sub-systems
    • Download using ftp
    • Run shell scripts
    • etc.

Better breakpoint management in a multi-core environment

  • Create a first-class object representing breakpoint "scope".  I.e. which targets/threads should a breakpoint should be installed with.
  • Create a linking between projects, launches and breakpoint scopes.

Power User features

*Scripting/Macros

  • A feature for executing a list of "actions" is already implemented in CDT.  It could be made more generic and moved to platform.
  • Scripts should be capable of:
    • Debugger operations
      • Run control
      • Breakpoint control
      • Reading/Writing memory
    • UI operations
      • Showing data in views.  This could be problematic with existing views architecture, perhaps "quick" views could be used instead.
      • Positioning editor.
  • Users should be able to "record" scripts based on a series of actions in the debugger.
  • I think the new command framework could provide some of the infrastructure for this feature.

*Common API for creating breakpoints

Currently, there is no single non-UI API for creating breakpoints.  This is a blocking feature for any kind of meaningful scripting support.  We should investigate to see if it makes sense to provide such an API.

Integration with static symbols

Currently static symbol databases and debugger symbol data retrieved from object files don't mix very well.  We should investigate to see if it would be possible to integrate the UI of the two a little bit better.  But currently, the only use cases I can think of are

  • Creating method breakpoints from the outline views and from the editor by right-clicking on the method declaration.
  • Showing method breakpoints in the editor gutter based on static symbol information.
  • Provide access to static (in addition to debugger) symbol information when creating a symbol breakpoint or choosing the object entry point.

*"Quick" views for debugger data

Quick outline (Ctrol-O) and type hierarchy (Ctrl-T) views accessible from the editor, as well as javadoc toolstips and method completion have made the experience of writing java code much more enjoyable.  Debugging seems ripe for similar kind of workflow improvement.  Some ideas for better debugger workflow are:

  • A smart watch view that only shows data relevant to the selected context.  It should also be capable of displaying more than just variables and registers, such as threads, breakpoint status, memory blocks, etc.
  • Quick views for Variables, Registers, Watch, and Memory.  Or better yet, a quick view version of the smart watch dialog mentioned above.
  • Interactive popups in the editor for variable values.  To allow the user to drill-down through the data.

Oddly enough, these ideas may not even require any changes in platform, but could be implemented as extensions.

*Truly integrated Java/C debugging

By truly integrated, I mean I imagine stepping into a JNI call in java and seamlessly transitioning to C debugging.  By seamlessly, I mean: the Debug view should have a single debug target, which is showing a stack trace with both java and C stack frames.  I think the only way we'll achieve this kind of integration is by writing UI layer which is reading data from both the Java and C debuggers, which I imagine this would be a lot easier to do if the java debugger was implemented using the DSF services framework.

*User customizable views

This should mostly just be an extension of DSF view-model functionality, but some more platform support may be required.  Users should be able to customize the contents in following ways:

  • Change the format of labels in Debug views.  The Debug view is especially confusing to our users because it shows labels made up of strings that repeat each other and use unfamiliar concepts, such as launch configuration names and process objects ("the refrigerator icon").
  • Change the layout of views
    • Let users hide the process ("refrigerator) icon, and channel std-io through the debug target instead.
    • Let users hide the debug target icon in debug view, and show threads directly below the launch node.
    • Let users hide the stack frames in Debug view and show a stack trace view instead, or use a "quick" view to select the current stack frame.
    • Let users hide register groups in register view.
    • Let users show a "history" node as a child of variables/registers.
  • Create custom views with custom content, such as
    • a stack frame view,
    • a history view with a single variable/register
    • debug targets view (as opposed to launch history view, i.e. the debug view).
    • etc.

*Pin + Clone

We seem to have talked about this one for years on end but we still don't have a complete picture on how this should work.

UI Polishing

*Better UI for breakpoints and IP markers in Editor

The biggest complaint here is that an instruction pointer can obscure a breakpoint and multiple breakpoints on the same line have no visual indication.  This is more editor work than debugger work, but it's a thorny deficiency in the debugger that has been around for a long time.  One possible solution may be a dedicated editor or annotation model just for debugging, as opposed to always sharing the editor with compiler static analysis, etc.

*Source Lookup UI Improvements

The source lookup UI is somewhat clunky by making the user walk a huge dialog tree to accomplish simple tasks.  It also lacks certain features such as showing a table of source files from the debugger and how they map to host source files.


_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev




--
Mariot Chauvin


_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev

Back to the top