Jump to: navigation, search

Difference between revisions of "DSDP/DD/DisassemblyView"

< DSDP‎ | DD
Line 1: Line 1:
 
This is the Disassembly Sub-group
 
This is the Disassembly Sub-group
  
Lead: Chris Recoskie (TI) - temporary lead<br>
+
Lead: Patrick Chuong (TI)<br>
 
Members: Wind River
 
Members: Wind River
  

Revision as of 10:04, 2 June 2006

This is the Disassembly Sub-group

Lead: Patrick Chuong (TI)
Members: Wind River


Requirements

Note: These requirements are build on top of the current CDT disassembly, not all existing feature is spelled out here.

  • R1 Generic disassembly view
  • 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


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?