Difference between revisions of "DSDP/DD/MemoryView"
(Update with subgroup call outline)
m (→Memory View Technology Subgroup Call (12/3/2006))
|Line 143:||Line 143:|
** List of TODOs?
** List of TODOs?
* Updates subgroup members (Ted, John and )
Revision as of 13:48, 4 December 2006
This is the Memory View Technology Sub-group
Lead: Samantha Chan (IBM)
Members: Ted Williams (WR), John Cortell (Freescale), Ken Dyck & Mark Melvin (AMI)
Potential Post-3.2 Work Items
[Memory View] Support for Save, Load and Fill functions in table renderings
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)
- Overview of the post-3.2 work items and what I think about them.
- Update on the import / export feature.
- Update on the import/export feature.
- Update on Address Space Support.
- Plans for the work items.
- Plans for the next Memory View Subgroup Call
- 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)
(Just an outline on what we will be talking about. I will update with meeting minutes after the meeting.)
- Eclipse 3.3 Plan for Memory View (Samantha)
|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
- 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
- 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?
- Updates from subgroup members (Ted, John and Ken)