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/MemoryView"

< DSDP‎ | DD
(Initial list of work items)
Line 4: Line 4:
 
Lead: Samantha Chan (IBM)<br>
 
Lead: Samantha Chan (IBM)<br>
 
Members: Ted Williams (WR), Freescale, AMI
 
Members: Ted Williams (WR), Freescale, AMI
 +
 +
 +
== Potential Post-3.2 Work Items ==
 +
'''[Memory View] Support for Save, Load and Fill functions in table renderings
 +
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=100080 Bug 100080]'''<br>
 +
Support for exporting and importing memory blocks to/from external files.<br>
 +
<br>
 +
'''[Memory View] Support for disjoint memory [https://bugs.eclipse.org/bugs/show_bug.cgi?id=117498 Bug 117498]'''<br>
 +
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.<br>
 +
<br>
 +
'''[Memory View] Allow the Memory View to run without an active debug session [https://bugs.eclipse.org/bugs/show_bug.cgi?id=132903 Bug 132903]'''<br>
 +
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)<br>
 +
<br>
 +
'''Better Support for Multiple Memory Views'''<br>
 +
There can be more than one memory views 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.<br>
 +
<br>
 +
'''Update Policies in Memory View'''<br>
 +
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.<br>
 +
<br>
 +
'''More Interesting Memory Renderings'''<br>
 +
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.)<br>
 +
<br>
 +
This is just a list of things that I can think of looking at the bug list.  I would update as I gather more feedback.  <br>

Revision as of 17:19, 28 April 2006

This is the Memory View Technology Sub-group


Lead: Samantha Chan (IBM)
Members: Ted Williams (WR), Freescale, AMI


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.

[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.

[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)

Better Support for Multiple Memory Views
There can be more than one memory views 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.

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.)

This is just a list of things that I can think of looking at the bug list. I would update as I gather more feedback.

Back to the top