DSDP/DD/MemoryView

This is the Memory View Technology Sub-group

Lead: Samantha Chan (IBM)
Members: Ted Williams (WR), John Cortell (Freescale), Ken Dyck & Mark Melvin (AMI)

3.5 Work Items

Memory View Workflow Enhancement - Owner: Ted
We would like to break this up into smaller work items to improve memory view workflow:
1. Provide a customizable and global "Go To Address" bar at the top. User no longer goes to multiple modal dialogs to add memory blocks and renderings.
2. Provide an ability to hide the Memory Monitors pane, and allow the view to operate without the Memory Monitors pane. We need to make memory monitors navigation more visible if the Memory Monitors pane is not present. Consider adding navigation toolbar buttons as opposed to having a drop down menu.
3. Allow the Rendering View Pane to host memory renderings from different memory blocks. Is this something customizable by model?
4. Provide an ability to allow models to configure how the Memory View should be laid out. This allows models to hide the second view pane.

Contribute Traditional Memory Rendering to Platform - Owner: Ted
1. Provide a patch in the context of the debug platform so we know how it will fit in the platfrom
2. Need to clean up implementation and consider which part of the rendering should be declared as APIs

Proposed Work Items for 3.5:

Work Item	Priority	Target Milestone	API Required?	Owner
Bug 214956 Go To Address Bar	P1	M5	Y	Samantha
Bug 257843 Enhancement to Go To Address composite	P2	Deferred	N
Bug 257837 Memory View Import/Export	P1	M5	Y	Ted
Bug 257838 Allow debug model to conrol action visibility - need to schedule design meeting	P1	M6	Y	Ted
Bug 257839 Memory View Find / Replace	P2	Deferred	Y
Bug 257840 Deprecate IMemoryBock	P3	Deferred - E4	Y
Bug 257841 Refresh action & API invalidate content	P2	M6	Y	Ted
Bug 257842 Expression Evaluation API	P1	M5	Y	Ted
Bug 257844 Copy address action	P3	Deferred	N
Bug 257847 Support for update policy in table rendering	P2/P3	Deferred - E4	Y
Bug 257845 RenderingViewPane needs to be API	P1	M6	Y	Samantha
Bug ??? More fine-grained control for debug change events	P2	M6	Y	Ted

Next Meeting: Design meeting for Bug 257838 Jan 14, 2009, 2 PM EST

Potential Post-3.2 Work Items

[Memory View] Support for Save, Load and Fill functions in table renderings Bug 100080
Support for exporting and importing memory blocks to/from external files.
Owner: John Cortell

[Memory View] Support for disjoint memory Bug 117498
On some platforms, the system may have large chunk of memory that is not accessible. The Memory View currently displays "non-readable" memory as question marks. It would be nice if the rendering can hide memory that is not readable.
Owner: Ken Dyck and Mark Melvin

[Memory View] Allow the Memory View to run without an active debug session Bug 132903
The Memory View has always been tightly coupled with the Debug View. The view assumes that there is a debug session running and listens for certain debug events for updates. With the introduction of debug context manager, we should look at decoupling the Memory View from the Debug View and remove assumptions on having a debug session. This allows other tools to make use of the Memory View without writing a debugger. (e.g. reading a dump file)
Owner: Ted Williams

Better Support for Multiple Memory Views
There can be more than one memory view opened. However, there is no way to pin its content to a certain debug context. We need to investigate how we can better handle multi-views scenarios.

Update Policies in Memory View
The table renderings provided by the platform supports updates policies. One can customize how/when a rendering should be updated. It would be nice to investigate how we can take advantage of the update policy support in the Memory View.
Owner: Samantha Chan

More Interesting Memory Renderings
The platform provides a set of renderings that display a memory block in the traditional table format. We can look at representing a memory block in some other interesting formats. (gif, bar graphs, etc.)
Possible rendering: disassembly rendering in the Memory View Bug 27892

Address Space Support in Memory View Bug 114528
The platform supports address space using flexible hierarchy, retargettable actions and allowing clients to customize labels in the view. Models that need to support address space should consider using the new features to better present address space information. For example, CDT should consider providing address space suport by taking advantage of the new features and allowing its clients to present address space information to the Memory View. In addition, we should also look at the current debug framework and determine if additional enhancements are required. (e.g. do we need new APIs?)
Owner: John Cortell

Support for Volatile Memory
Memory could change in the background while the debug session is suspended. Make sure updates are done properly.

Ability to only read memory when requested
On some systems, there are side effects reading memory from some region. We need a way to allow users to control when to stop / start reading these memory.

Better Support for Write-only Memory
Some memory can only be written and cannot be read. We need to allow user to write those memory. Currently, there is no way to verify what's being written onto the system.

Memory View Technology Subgroup Call (5/30/2006)

Agenda:

• Samantha:
• Overview of the post-3.2 work items and what I think about them.
• Ted:
• Update on the import / export feature.
• John:
• Update on the import/export feature.
• Update on Address Space Support.
• Plans for the work items.
• Plans for the next Memory View Subgroup Call

Meeting Minutes

• The meeting is to find out what everyone is up to and to assign owners to these work items. We wish to have the owners do some more detailed investigation or requirement analysis on the work items. We also wish that the owners maybe able to prototype or do the initial design.
• Samantha gave an overview of the work items and possible ways of implementing them.
• AMI also has the following requirements:
• Support for Volatile Memory - memory could change in the background while the debug session is suspended. Make sure updates are done properly.
• Ability to only read memory when requested - on some systems, there are side effects reading memory from some region. We need a way to allow users to control when to stop / start reading these memory
• Better Support for Write-only Memory - Some memory can only be written and cannot be read. We need to allow user to write those memory. Currently, there is no way to verify what's being written onto the system.
• Ted gave an update on the import / export feature. John will take over this feature.
• WindRiver's Memory Rendering: Ted also gave an update on the status of the renderings that he showed in the last DSDP meeting. The code has been attached to Bug 137391 and is subsequently checked into DSDP's CVS.
• Import / Export Memory: John will be working on the import/export feature for the next 2-3 months. He hopes to get to do the design documents and prototype and have the subgroup review it when done. This feature is targetted for 3.3.
• Address Space Support: John has started working on Address Space support for CDT. The feature will be added to CDT. He is successful at getting a custom dialog to come up when user adds a new memory block. He has added support from CDT to ask for available address spaces through the CDI interfaces. Available address spaces are presented to user using a combo box in the customized dialog. When address space support is turned on, user has to enter the actual address. User cannot monitor an expression. It does not make sense to monitor expression if address space is used.
• Todos for Address Space Support:
• Customize labels in renderings
• Categorize memory blocks based on adddress spaces in the tree viewer.
• Each of us will take on a work item and do more requirement analysis / design on the individual work items. The breakdown is as follows:
• John: Import and Export + Address Space Support
• Ted: Using the Memory View without an active debug session
• Ken and Mark: Investigate support for disjoint memory.
• Samantha: Update policy for the Memory View.
• We will meet again in 6 weeks and give an update on requirements / designs on the individual items.

Memory View Technology Subgroup Call (12/3/2006)

• Eclipse 3.3 Plan for Memory View (Samantha)

Work Item	Status	Comments
Promote Memory View related provisional APIs to public APIs	Deferred
Migrate Memory View tree viewer to new Tree Model Viewer	In Progress
Migrate table renderings to use new model viewers	In Progress	Discussing on which viewer to use.
Support for pin and clone	Not Started	Waiting for pin and clone discussion to start.
More flexible pre- and post- buffer size	Time Permitting	Must be done before M5
More flexible page size	Time Permitting	Must be done before M5
Bug Fixing	Not Started
Flexible Hierarchy in table rendering	Time Permitting	This will be looked at when migrating the rendering. But not committing to this work item.
Import and Export Memory	Deferred	No resource to commit to this work item.
Memory Search Function	Deferred	No resource to commit to this work item.
Multi-cell Highlight	Deferred	No resource to commit to this work item.
Endianess in Hex and ASCII Rendering	Deferred	No resource to commit to this work item. Will consider if there is a contribution.
Representations in table rendering	Deferred	No resource to commit to this work item.
Support for variable access size in renderings	Completed	Agreed that this support should be added to model instead.

• Table Viewer vs Tree Viewer in table renderings (Samantha)
  • Considering to use the new Tree Model Viewer to re-implement AbstractAsyncTableRendering
  • Pros:
    • May allow us to support disjoint memory
    • Eclipse Debug Team does not have to implement a new table viewer
    • Tree Structure may be more flexible for showing other things in the memory view: e.g. embedding additional information in the tree structure inside the rendering
  • Cons:
    • More work to migrate existing table rendering.
    • TreeViewer does not support cursor - need to ask SWT / Debug Team to implement the cursor.
    • Show / Hide Address Column may be an issue? Not sure how the viewer will look if the tree is hidden.
    • Break existing clients who are subclassing from AbstractAsyncTableRendering - not an issue to break provisional APIs, but migration will be more painful.
    • Customer maybe shocked to see such a big change. (How did people react to changes in Variables View?)
• Update on Traditional Rendering from DSDP (Ted)
  • List of TODOs?
  • Plans?
• Updates from subgroup members (Ted, John and Ken)

Minutes/Notes

Attendees:
Ted Williams (Wind River)
John Cortell (Freescale)
Ken Dyck (AMI)
Todd Lee (AMI)
Alain Lee (TI)
Samantha Chan (IBM)

• 3.3 Plan:
  • Focus on keeping up with changes from the platform
  • Features listed as deferred are not committed for 3.3. If contributions are provided for some of the features, Samantha will consider adding those to the 3.3 plan.
• Moving from table viewer to tree viewer in table rendering:
  • AMI sublcasses from AbstractAsyncTableRendering, but does not access the viewer. So, this will not be a lot of impact for them.
  • Samantha is to create screen shots to gather more feedback when prototyping.
  • Usability Concerns: Tree viewer with columns will still look a lot like a table, so this should not be too disconcerting for users.
• Traditional Rendering:
  • Working on bug fixes
  • Need hardware to test addressable sizes > 1
    • Working on a simulator to test this feature.
    • Suggested to use the sample adapter from EclipseCon to test this.
    • Ted is to post TODOs and plans on Wiki
• Spirit
  • Support for Spirit should be separated from the platform.
  • Some clients may not pick up Spirit.
  • The platform should only know about the memory block. How the memory block retrieves memory, via Spirit or talking to a debug engine, should be transparent to the platform.
• Additional Attributes in Memory Byte
  • Clients have additional attributes that need to be represented in MemoryByte
  • Two ways of adding support to these attributes:
    • Add more flags in the platform's MemoryByte and the table renderings need to support these additional attributes.
    • Clients subclass from MemoryByte and provide custom content adapters to handle the new attributes.
  • Need to make sure the strategy is flexible since not all clients require these additional attributes.
  • Ken is to provide a list of the custom attributes and we will decide if any of these should be added to the platform. Here it is:
    • volatile - contents of memory can change from read-to-read
    • read has side effects - reading a value causes the state of the system to change
    • executable - the memory can be fetched and executed by the target
    • control registers - the memory consists of memory-mapped registers
• Go to address API
  • Bug 163581 from DSDP
  • Alain is to add this feature request to the platform for this to be added to the 3.3 plan.
• Updates from Subgroup Members:
  • John
    • Worked on the import/export feature. The feature was implemented with an internal framework. It requires too much work to contribute the feature back to Eclipse. (e.g. legal restrictions, etc.)
  • Ken
    • Todd is working with Ted on the traditional rendering.

Memory View Update (2007/01/25)

Work Item	Status	Comments
Promote Memory View related provisional APIs to public APIs	Deferred
Migrate Memory View tree viewer to new Tree Model Viewer	Completed
Migrate table renderings to use new model viewers	Deferred	Continue to use AsynchronousTableViewer. Will move viewer to internal packages.
Support for pin and clone	Not Started	Waiting for pin and clone discussion to start.
More flexible pre- and post- buffer size	Completed	Creating user preference to allow user to configure the number of lines to buffer.
Create IGoToAddress Interface	Completed	IRepositionableMemoryRendering
More flexible page size	Time Permitting	Must be done before M5
Bug Fixing	Not Started
Flexible Hierarchy in table rendering	Deferred
Import and Export Memory	Deferred	No resource to commit to this work item.
Memory Search Function	Deferred	No resource to commit to this work item.
Multi-cell Highlight	Deferred	No resource to commit to this work item.
Endianess in Hex and ASCII Rendering	Completed	Used patch as based of new Hex Integer rendering
Representations in table rendering	Deferred	No resource to commit to this work item.
Support for variable access size in renderings	Completed	Agreed that this support should be added to model instead.

New Attributes in MemoryByte?

This is a list of attributes provided by Ken.

Some questions that need to be answered before we decide if they should be added to the platform:

• How should the UI handle these attributes?
• How common are these attributes in a device debugging environment?
• What are the benefits of adding them to the platform?

Attributes and Initial Thoughts

• volatile - contents of memory can change from read-to-read
  • Question here is that does the content change because of the read? or is there some other things causing the memory to change?
• read has side effects - reading a value causes the state of the system to change
  • The UI should not read content from these MemoryBytes unless initiated by the user.
  • When the memory rendering is first created, the rendering will ask the memory block for a block of memory. If the memory read will change the state of the system, the memory block should return MemoryByte with the new "read has side effect" attribute. It is up to the memory block to decide if it will go to the backend to read that memory.
  • The rendering must provide custom visual indicators to show that the memory is has side effect when reading. Having "??" may not be sufficient.
  • The rendering must provide an action to allow the user to force a read of the memory to show its value. Reading will cause the system to change and may cause other views like the variables view / registers view to update.
  • As the user run / step through the debuggee, the rendering should not update the memory unless explicitly told to do so.
  • Do we need more fine grained control on the update policy? The update policy can control updates of the entire rendering. However, it does not allow models to tell if a certain range should be updated.
  • How should we define this attribute? READ_ON_DEMAND? The idea is that the rendering should not update this memory unless explicitly told to do so? The memory block should not go to the back end to fetch memory unless explicitly told to do so.
• executable - the memory can be fetched and executed by the target
  • UI needs to have visual indicator to show that the memory is executable.
  • There needs to be actions to allow the user to execute a range of memory.
  • We may want actions to tie this memory to the disassembly view?
• control registers - the memory consists of memory-mapped registers
  • Some how tie this type of memory byte to the registers view?

Additional Requirements on the Platform

Some of these attributes translate to more requirements on the platform:

• Ability to have more fine-grained update policy. Models may need to be able to control if a range of memory should be updated or not.
• Ability to contribute different context menu to the rendering based on the current selection of MemoryByte. Context menu actions are contributed to a rendering via object contribution / view contribution. We do not have a good story on how the user can contribute actions based on the current selection of memory byte.
• Multi-cell select in the rendering.