| [jdt-debug-dev] Debug Work Items for 2.1 and Beyond |
2.1+ Debug DirectionsThis document is a list of potential debugger work items and areas of investigation for 2.1 and future releases of Eclipse. Items appearing on this list are not committed to be delivered in any specific release. Possible Work Items
§ _expression_ level stepping – requires experimenting with byte code level stepping, and “on the fly compilation” (to get source extra positions). Approach is to compile compilation unit when entered (suspended), and compare byte codes to that of running class file. If the same, we can then support _expression_ level stepping, via “StepRequest.STEP_MIN” (instruction level stepping). Need to determine if the compiler will give us the required source positions. § Instruction pointer display in editor (highlight or marker) § Optimizations in Java debug model for deep stacks (lazy/less JDI calls) · Refactoring § Java launch configurations – provide support for updating Java launch configurations as main types/projects are renamed, moved, deleted, etc. Need to identify refactorings that may be supported, and how we can automatically update launch configurations. · Evaluations § AST Statement Evaluations – provide support for evaluating statements as well as expressions. § Evaluation problems when runtime JRE does not match workspace (project) JRE. We compile and interpret against the workspace JRE, but run against a different JRE. · Debugging languages compiled to Java § Better support for Java debug model wrappering/rendering – improved support for languages compiled to Java. Need to identify issues/get feedback from teams that have experimented with this. Suggestions are to work via adapters (i.e. java debugger should operate on core debug elements that provide appropriate adapters. This way, the java debug actions work on debug models that do not implement the java debug model interfaces, but have access/proxy to a java debug model). Another suggestion is to provide a proxy debug model framework so other implementers do not have to re-implement everything. § Support for strata in JDI implementation · Breakpoints § Breakpoints in non-workspace source (better stand alone debug support) § Improved Breakpoint location verification § Refactoring – preserve breakpoints when a type is moved/renamed, etc. § Improved Method entry/exit breakpoints – use line breakpoints for efficiency. Must use exit events for exit breakpoints, but can experiment with deferring exit events until a method is entered. Should be able to support source entry/exit breakpoints. § More flexible exception breakpoints (http://bugs.eclipse.org/bugs/show_bug.cgi?id=17830) § Breakpoint groups § Stop in main option § Drag and drop within same compilation unit (i.e. line breakpoints) § Condition history in properties dialog § Persistence/Creation lifecycle problem. If breakpoints are loaded (i.e. from persisted markers), in response to a workspace delta, and a breakpoint marker is modified, we fail (cannot modify workspace during a resource delta). Problem requires investigation. · Scrapbook § Breakpoints in scrapbook source § Display source when stepping in scrapbook § Hide scrapbook VM/process until a user breakpoint is hit · Launch Configurations § User friendly support for defining system properties in local Java launch configurations (i.e. Dx=y). § Show generated command line for a launch, and allow user to edit § History in “shared location” fields § Import/export for local launch config sharing/workspace migration. § Adding a project to the classpath/source path should add exported entries too (http://bugs.eclipse.org/bugs/show_bug.cgi?id=18627) · HotSwap § Better support for hotswap in inner classes (http://bugs.eclipse.org/bugs/show_bug.cgi?id=19608) § Warning when hotswapping code with compile errors (i.e. allow user to correct before swap) § Option to disable HCR per launch · Variables § Pluggable display/formatting for inspectors. Provide code snippet to compute ‘toString’ for a specific class (likely requires AST statement evaluation). § Enhance value changing – support “null”, special chars (‘\n’), Unicode, hex, etc. (http://bugs.eclipse.org/bugs/show_bug.cgi?id=1551)
§ Can we reliably support thread termination? We removed this feature in 2.0 (the implementation caused WAS VM to crash – setting an instance of ThreadDeath to be “non GC-able”). § Currently, resuming a thread collapses the thread and clears the variables view. This is undesirable when debugging in a tight loop with a breakpoint. Is there a way to perform incremental update, as when stepping? How do we provide this support in the generic debug model and UI?
§ Investigate debugging from Java into natives and back
§ Java expressions that are evaluated when a thread suspends § Could be bound to a particular location
§ Need to identify use cases and how this can be implemented VM independently. · Debug Events § Modifying the debug model during event dispatch. Problems arise when debug event listeners modify the debug model during event dispatch, thus changing the state of the model for subsequent listeners. For example, the variables view starts an implicit asynchronous evaluation to calculate the “toString” of objects when a step ends. This effectively resumes a thread, which can cause problems in the debug view, which attempts to render threads/stack frames. The debug view may receive the “step end” event after the variables view. Currently, there is not protection in place for such problems. · Console § Generic console support – need to coordinate with workbench team. Could we provide a generic console and submit it to the workbench? § Max buffer size to avoid memory overflow/unbounded cache · Exception Handling § Guard against exceptions in extension points when calling methods on extensions, and instantiating extensions. § Currently we log errors for some expected, properly handled exceptions. This causes uneccessary error logging which users perceive as errors. |