Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "DSDP/DD/DisassemblyView"

< DSDP‎ | DD
m (Disassembly Subgroup Meetings)
 
(16 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This is the Disassembly Sub-group
+
This is the Disassembly Sub-group<br>
  
Lead: Chris Recoskie (TI) - temporary lead<br>
+
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>
  
== Requirements ==
+
2. ''[[Disassembly window management]]''<br>
Note: These requirements are build on top of the current CDT disassembly, not all existing feature is spelled out here.
+
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>
  
* R1 Generic disassembly view
+
3. ''Disassembly specific actions''<br>
* R2 Mixed mode view (2 available options, we might just need one)
+
** R2.1 Integrate with editor, source base disassembly
+
** R2.2 Standalone (toggle between disassembly and mixed mode in the same view), address base disassembly
+
* R3 Follow the PC location and if PC is out of the current viewing address, than update the view to show the PC, option to disable this feature
+
* R4 Ability to view beyond the current stackframe
+
** R4.1 Ability to scroll through whole program address
+
** R4.2 Ability to show the view at any given address and symbol that resolved to an address
+
*** R4.2.1 This can be a combo box placed in the toolbar with history values for quick access
+
* R5 Shouldn't blank out the view when target is running, option to blank out the view
+
* R6 Ability to set software breakpoint, hardware breakpoint, and any breakpoint provided by the debugger
+
** R6.1 Double clicks in the left margin to set software breakpoint
+
** R6.2 Context menu to set hardware breakpoint and additional breakpoint type provided by the debugger
+
** R6.3 Ability to set multiple breakpoint on the same address
+
** R6.4 Ability to resize the left margin to show multiple breakpoint icons
+
* R7 Interlace assembly text and symbol for quick reference
+
* R8 Ability to change the PC location
+
** R8.1 Run to cursor
+
** R8.2 Set PC to cursor
+
* R9 Multipe PC indicators (target can have multiple addresses for a single execution packet)
+
* R10 An icon to indicate to the user opCode might not be valid (on some target, it is not possible to locate the valid start address if the user scroll around in the view)
+
* R11 Ability to set foreground and background color
+
* R12 Copy text to clipboard
+
* R13 Print support
+
* R14 In-place editing of the opCode
+
  
 +
== Disassembly Subgroup Meetings ==
 +
* [[DSDP/DD/Disassembly_Phone_10-January-2008]]
 +
* [[DSDP/DD/Disassembly_Phone_17-January-2008]]
  
 
+
[[Category:DSDP]]
== Additional Notes ==
+
[[Category:DSDP/DD|DisassemblyView]]
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 base and also see the related source line without having to browse the source file. Reusing the editor's syntax highlight scheme.
+
** 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.
+
** 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?
+

Latest revision as of 14: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.

3. Disassembly specific actions

Disassembly Subgroup Meetings

Copyright © Eclipse Foundation, Inc. All Rights Reserved.