[cdt-debug-dev] CDT debugger features

[John Cortell <cortell@xxxxxxxxxxxxxx>]

Attached is a list and description of core features Freescale requires in a 
debugger and therefore deems necessary in Eclipse/CDT, whether this is as a 
part of common technology or as a Freescale add-on.  We wish to avoid 
duplication of effort, and as such, would like to solicit feedback from the 
community on the various objectives with regard to the following:

- find out if one or more of these features are already on the CDT 3.1 road-map
- find out if any individual contributors already have their sights on 
these features--perhaps even have draft or complete implementations not yet 
submitted for adoption
- solicit feedback that will help us develop the features in a way that 
best benefits the community and makes the features more likely to be adopted

The items vary in priority and level of difficulty, but they are listed in 
no particular order.

John

1. Change the Program Counter.
The user would be able to change the current execution point in a stopped 
thread by either (a) moving the PC arrow, or (a) right clicking on a line of 
code and hitting a "Set PC" item in the context menu.

2. Display variable addresses or containing register in Variables view.
Perhaps with the addition of a column to the view, the address or
containing register of each variable would be displayed in addition to
its value.

3. Selectable scope for Variables view:
	- all: view all local variables in the current function
	- live: view only variables that are visible within the current PC 
	  context/scope
	- auto: view only variables referenced within a few source statements 
	  of the PC.

3.1. Include global variables in Variables view. 
Global variables referenced in a function would be displayed along with local 
variables. A horizontal divider would separate the two types of variables. This 
feature requires specialized debug information, and as such, would only be available 
with particular toolsets. 

4. Enhanced breakpoints.
User would be able to attach an action (log a message, invoke a sound, run a 
script, skip a statement, or update views) with the option to resume or suspend 
execution.

5. Breakpoint templates.
User would be able to create a breakpoint template to describe a commonly-set 
breakpoint that is non-trivial in its configuration. Setting a breakpoint of 
that type at a particular source location would be quick and painless given 
the template. For example, consider a developer has coded a global variable 
to control debugging called "gDeepDebug". Rather than repeatedly set a breakpoint
with the condition "gDeepDebug == 1", one could create and use a template.

6. Multiple thread debug context
The user would be able to step and control two (or more) threads through dedicated
windows which can be seen simultaneously. Potential approaches are currently
being discussed.

7. System Browser
A window that, at a minimum (for targets with an OS), shows all running processes 
on the target. Each process node can be opened up to display threads and their state.
In addition to process/thread information, any configurable hierarchy of Operating 
System or Target Hardware information could be displayed. Information other than the 
process/thread list would be hosted as opaque data. That is, the view would simply 
act as a host for target specific information that the debugger backend would populate.

8. Attach to process.
In the System Browser, the user would be able to attach the debugger to a 
process.

9. Module symbol loading enhancements
User would be able to tell the debugger how it should go about deciding what 
modules to load symbols for
	- all dlls
	- all non system dlls (debugger would differentiate these)
	- none
Also, user would be able to pre-load symbols for specific dlls, and prevent 
the loading (symbols) of others. Also, users would be able to load/reload/unload 
symbols for any arbitrary executable.  Relocation information for the newly loaded
symbols could be obtained from the debug connection, or provided by the
user.


10. Linetable tick marks.
The debugger would use a visual cue (tick marks) to let the user know where 
he/she can set breakpoints in source.

11. Auto-update Views
Based on a configurable time interval, the debugger would "silently" suspend 
the target or query the target live (if the target debug-interface supports this) 
to update any applicable views: registers, variables, expressions, etc. If the 
target is suspended, it would be automatically resumed after getting the updated 
view information. The user would be oblivious to the brief stop in the target. 

12. Support for address spaces.
To properly support targets that have the notion of address spaces, all 
instances in CDT where a memory location is assumed to be a single integral 
value would be enhanced to use a more abstract definition of a memory location. 
This would allow for an address space identifier to be associated with 
variables, expressions and code locations. Also, some minor UI related changes
to support the encoding of the address-space identifier in a memory address
string.

13. Optimized code debugging (OCD) capabilities.
In optimized code, the correlation between source and assembly code often 
breaks the conventional flow. To properly support mixed view debugging of 
optimized code, disassembly and source need to be presented to the user 
side-by-side. Other OCD enhancements are the ability to set multiple 
breakpoints within a given optimized line of source code, and the use of 
specialized step operations.

14. Generic command line interface
The user would be able to drive an Eclipse/CDT debug session via a command 
console--not by issuing commands specific to the low level debugger protocol 
(e.g., gdb), but by using a generic command syntax that could be used with 
all CDT debug sessions. This interface would support a scripting language 
(e.g. TCL or perl) and would support the invocation of script files.

15. RTTI support.
User would be able to see the true type of a polymorphic class. The debugger 
would get this translation from the debugger plugin.

16. Cached-source for debugging.
During the course of a debug session, the user can modify a source file for 
use in a subsequent compile/debug cycle.  The cached-source for debugging 
would be maintained & displayed for the remainder of the current 
debug-session and future debug-sessions until the subsequent compile/build 
takes place.  This feature might have some dependencies on #6 (Multiple thread 
debug context).

17. Just-in time debugging.
On host OS's that support invoking a debugger when an application crashes, the 
user's request to debug the crash (via the OS's crash dialog) would 
automatically launch Eclipse and attach it to the crashed program.

18. Debugging of project-less executables.
The user would be able to debug a standalone executable by using an Import
wizard to create a project and automatically register a launch configuration
for the project. Through the use of an enhanced binary parser, the project 
would be populated with the source files referenced by the debug information 
in the executable. These sources would exist in the projects as links, and in 
a mode that would exclude them from the build process. In addition, the user 
would be able to add executable debug contexts for project-less shared 
libraries. The sources for such executables would be included also as links 
that are bypassed by the build process. The symbols for these DLLs would 
automatically be pre-loaded on a debug launch. The user would be able to 
pre-set breakpoints via the sources for the DLLs.

19. Memory window enhancements.We realize CDT now uses the Memory Window from 
the Eclipse base, and we plan on posting these requests/intentions to the 
platform mailing list, but we include it here for completeness.

a. Toggle endian-ness of memory units
The Eclipse Memory window allows the user to choose the unit size. For 
size > 1, we'd like the ability to flip a switch and have the bytes display in 
reverse order. This is helpful is viewing, say, an array of int's on a little 
endian target. 

b. Save, Load and Fill functions
The user would be able to save the contents of the Memory View to a file--one 
which could then be re-load into the Memory View, thereby setting memory with 
those values. Also, the user would be able to fill in a range of memory with a 
particular value (value may be more than one byte),

c. View memory as source, mixed, or disassembly. 
Support for disassembly is already on the 3.0/3.1 roadmap. We'd like to extend 
that to include mixed and source.

d. View memory as UNICODE. 
Much in the same way as it's currently displayed as singly-byte text (ASCII).

e. Set Watchpoint on memory range.
The user could select multiple continuous units and set a watchpoint. If the 
range exceeds the debugger's capabilities, an error msg would result.

f. Support address spaces.
The user could indicate the address space to view.