[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-debug-dev] Re: [platform-debug-dev] Debug Work Items for 2.1 and Beyond
|
This function is mainly for us dummies and/or beginners that forget or
don't know to set a breakpoint prior to debugging. (If a person is
doing remote debugging then they are taking extra steps anyway.) The
one problem that I see with doing this for one but not the other is
inconsistency, resulting in a less intuitive interface.
How do other java debuggers out there handle this, or do they?
Regards,
David
Darin Wright wrote:
>
> For #5 below (stop in main) - do you expect this to work for "local
> java apps" only, or also "remote java apps"?
>
> There is a technical issue: Setting a method entry breakpoint for a
> fully qualified method (i.e. type name, method name & signature)
> exhibits good performance (the same overhead as a line breakpoint).
> Setting a method entry breakpoint for a method name (i.e. any method
> named "main"), exhibits poor performance. I assume that stepping into
> main is only useful in the "local" case where you actually launch main
> (and we know the fully qualfied method name/signature). In the remote
> case, chances are that the "main" method is already long gone (and we
> do not know the name of the main class).
>
> (See bug 20869 for an explanation of method entry/exit breakpoints and
> related performance issues).
>
> Thus, I propse to add support for "stop in main" to local Java apps
> only. Do we agree?
>
> Darin
>
> David Sanders <dsanders@xxxxxxxxxxx>
> Sent by: To:
> platform-debug-dev-admin@xxxxxxxxxxx platform-debug-dev@xxxxxxxxxxx
> cc:
> 08/12/2002 04:32 PM jdt-debug-dev@xxxxxxxxxxx
> Please respond to platform-debug-dev Subject: Re:
> [platform-debug-dev] Debug Work
> Items for 2.1 and Beyond
>
> Hello,
>
> Here are some of the issues we've come across when wrapping the
> jdt debug model:
>
> 1. One issue that we have when wrappering the jdt debug model is
> that we have no way to override the jdt menu contributions to the
> launch and variable views (that we know of). Specifically the
> 'open on <x> type' menu items. These show the underlying java source
> code, which is not the language that the user is debugging. I would
> say that the solution would be to base the menu items on the current
> debug target id, but I'm not sure if this is the solution.
>
> 2. Another issue that we have is that our program programmatically
> sets underlying java breakpoints whenever the user sets a breakpoint
> in their source code (which is in another language). It would be
> nice if these java breakpoints could be 'invisible' in the breakpoint
> view by default. Currently, the user has to set the 'show only
> supported breakpoints' option. It would be nice if there was a
> visibility option and the breakpoint view would not show invisible
> breakpoints by default (the user could override this, of course).
>
> 3. Some JDIDebugElement methods cast IJava<xx> elements to JDI<xxx>
> unnecessarily, even when the method needed to be called is defined by
> the IJava<xx> element. This limits some of the ability for plugins
> to wrap/mimic these elements.
>
> 4. We have no way of calling the shutdown method of JDIDebugTarget
> because shutdown is not defined in IJavaDebugTarget, and the jdt
> plugin class that is responsible for shutting down the debug target
> expects a JDIDebugTarget to be registered, which it isn't (ours is).
>
> 5. The use should have the ability to debug without setting a
> breakpoint. (The debugger should be able to 'step into main'. This
> is already on the list, I believe.)
>
> Regards,
>
> David
>
> Darin Wright wrote:
> >
> > Not yet. We are still eagarly waiting for input from other
> developers
> > to help prioritize the features we will work on. If there are any
> > features/bugs/issues that are important to you, please let us know.
> >
> > Darin
> >
> _______________________________________________
> platform-debug-dev mailing list
> platform-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-debug-dev