The goal of this subgroup is to provide the debugger implementers with the UI components designed to display disassembly. Currently we are planning to contribute the resulting components to the CDT project with the gdb/mi backend (CDI and DSF) as a reference implementation. The public API of the disassembly package will be independent and can be used by any other model directly.<br>

−

Members: Wind River

+

+

'''Overview'''<br>

+

According to the discussion held by the DSDP/DD community ([[Disassembly Discussion]]) there is a demand to view the disassembly associated with a stack frame when the program being debugged is suspended, as well as the ability to disassemble an arbitrary range of memory. The latter can be implemented as a special memory rendering for the Platform memory view. The former requires a special window located in the editor area of Eclipse workbench (I prefer to call it "window" instead of "editor" to stress that there are no plans to make it editable, at least for now). There is also a set of actions associated with both of these components to support navigation, breakpoints, watchpoints, etc. The support of the run control actions is required for the disassembly window.<br>

+

'''Implementation'''<br>

+

1. ''[[Special viewer for both components]]''<br>

+

The description of a viewer that is based on the SourceViewer class and utilizes the ideas used by the flexible-hierarchy tree viewers. The document associated with the viewer is based on the generic disassembly presentation model. To plug into the viewer clients are required to implement a set of adapters.<br>

−

== User Requirements ==

+

2. ''[[Disassembly window management]]''<br>

+

This part describes the disassembly window management mechanism that controls the life cycle of a disassembly window. Memory renderings are managed by the memory view.<br>

''This should causes any disassembly display that is viewing the current disassemble region to update to reflect the change''<br><br>

+

−

+

−

'''Follow PC location and if PC is out of the current viewing address, than update the view to show the PC'''

+

−

*There should be an option to disable this feature<br><br>

+

−

+

−

'''The view should not be blank out when target is running'''<br><br>

+

−

+

−

'''Ability to set software breakpoint, hardware breakpoint, and any breakpoint provided by the debugger'''

+

−

*Double clicks in the left margin to set software breakpoint [''Default action'']

+

−

*Context menu to set hardware breakpoint and additional breakpoint type provided by the debugger

+

−

*Ability to set multiple breakpoint at the same address

+

−

*Ability to set multiple breakpoint at the same source location

+

−

*Ability to resize the left margin to show multiple breakpoint icons

+

−

*Icon should have different representation based on the breakpoint type, condition, and action<br><br>

+

−

+

−

'''An icon to indicate to the user opCode might not be valid [https://bugs.eclipse.org/bugs/show_bug.cgi?id=86882 Bug 86882]'''<br>

+

−

''On some target, it is not possible to locate the valid start address if the user scroll around in the view''<br>

+

−

''Program might have hold, it is not always continuous''<br><br>

+

−

+

−

'''The presentation of the disassembly display should be configurable [https://bugs.eclipse.org/bugs/show_bug.cgi?id=80209 Bug 80209]'''

+

−

*There should be an option to show interleaved assembly text and symbol for quick reference<br>

+

−

*The display column should be a user configurable option<br><br>

+

−

+

−

'''Ability to change the PC location'''

+

−

*Run to cursor

+

−

*Set PC to cursor<br><br>

+

−

+

−

'''Multipe PC indicators ''(target can have multiple addresses for a single execution packet)'''''

+

−

*In the editor, it should have a different PC indicator for source and disassembly text<br><br>

+

−

+

−

'''Copying text to clipboard'''

+

−

*It should be possible to highlight a section of disassembly text and copy it to the clipboard<br><br>

+

−

+

−

'''Print support'''

+

−

*Disassembly view

+

−

**Print selected text

+

−

**Print a user defined region

+

−

**Print visible area

+

−

*Editor

+

−

**Print current viewing editor window<br><br>

+

−

+

−

'''Automatic open the disassembly window if there is no source [https://bugs.eclipse.org/bugs/show_bug.cgi?id=81353 Bug 81353]'''

+

−

*When the target halted and the disassembly window is not open, the disassembly should open up and show the current PC location

+

−

*If a diassembly window is already open, than it should be reuse and update the start address to the current PC location

+

−

*There should be an option not to open the disassembly window<br><br>

+

−

+

−

== API Requrements ==

+

−

*There should be an API to configure to blank out the view when target running, it is upto the debugger to support this feature

+

−

*There should be an API to configure to disable disassemble [https://bugs.eclipse.org/bugs/show_bug.cgi?id=122013 Bug 122013]

+

−

*There should be an API to change the forground color and background color for each line of text

+

−

+

−

== Design Notes ==

+

−

Showing disassembly in the editor is the preferred solution, and it should be implemented as a contribution to an editor view an extension point or something similar (Mikhail Khodjaiants).

+

−

+

−

+

−

== Additional Notes ==

+

−

There are pros and cons for showing disassembly text in the editor (source base) and in a standalone view (address base).

+

−

* Address base

+

−

** Pros: Allows user to scroll through the entire program address space and also see the related source line without having to browse the source file.

+

−

** Cons: Source line might not match the order of the source line in the editor. This is the case when the compiler optomized your code or your code is located in fragmented memory address.

+

−

* Source base

+

−

** Pros: User can quickly corrolate the source with the opCode generated by the compiler. Reading highlevel C/C++ code is much easier than assembly code, and user has the option to flip to mixed mode to see the generated assembly code. Reusing the editor's syntax highlight scheme.

+

−

** Cons: It is not possible to scroll through the entire program address, you are lock in to the current opened file.

+

−

+

−

+

−

When source file is modified during debugging, we need to have visual indication to the user that the source doesn't match the mixed mode, and it is required to recompile and restart the session. Is this common sense to embedded devloper? Do we need to have a requirement?

+

[[Category:DSDP]]

[[Category:DSDP]]

[[Category:DSDP/DD|DisassemblyView]]

[[Category:DSDP/DD|DisassemblyView]]

Latest revision as of 13:59, 10 January 2008

This is the Disassembly Sub-group

The goal of this subgroup is to provide the debugger implementers with the UI components designed to display disassembly. Currently we are planning to contribute the resulting components to the CDT project with the gdb/mi backend (CDI and DSF) as a reference implementation. The public API of the disassembly package will be independent and can be used by any other model directly.

Overview
According to the discussion held by the DSDP/DD community (Disassembly Discussion) there is a demand to view the disassembly associated with a stack frame when the program being debugged is suspended, as well as the ability to disassemble an arbitrary range of memory. The latter can be implemented as a special memory rendering for the Platform memory view. The former requires a special window located in the editor area of Eclipse workbench (I prefer to call it "window" instead of "editor" to stress that there are no plans to make it editable, at least for now). There is also a set of actions associated with both of these components to support navigation, breakpoints, watchpoints, etc. The support of the run control actions is required for the disassembly window.

Implementation
1. Special viewer for both components
The description of a viewer that is based on the SourceViewer class and utilizes the ideas used by the flexible-hierarchy tree viewers. The document associated with the viewer is based on the generic disassembly presentation model. To plug into the viewer clients are required to implement a set of adapters.

2. Disassembly window management
This part describes the disassembly window management mechanism that controls the life cycle of a disassembly window. Memory renderings are managed by the memory view.