[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Enhancements for the Memory View in Eclipse 3 .2
|
Samantha,
It would help if the writing of the memory block to a file was
extendible. Our current debugger lets the user generate a (Motorola)
S-Record file, as well as binary and various textual representations.
Other tools providers might want other formats.
John
At 11:29 AM 11/30/2005, Samantha Chan wrote:
Hi Jerome -
Thanks for the feedback. It helps...
Re: Support for several MAU
The Memory View supports MAU larger than 8 bits. I believe you need CDT to
do something in this area to display MAU larger than 8 bits.
Re: Support target endianess
The Memory View also supports different target endianess. What you need
here is that CDT display correct values in the Registers View with
different target endianess.
Re: Support additional display mode.
The Memory View allows clients to contribute custom renderings. You can
easily have another display mode in a table format by subclassing from
AbstractTableRendering. If you want to render in another format, e.g.
tree, graphs, etc, you will have to create custom renderings.
You mention "Fractional..." in your slides. What does that mean? What
other renderings do you want support for?
Since you use CDT, is it correct that you only talk to CDT through the CDI
layer? i.e. you cannot contribute directly to Eclipse, you rely on CDT to
add custom renderings?
Re: Dump/Restore Memory
There is a deferred enhancement request similar to your requirement:
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=100080>https://bugs.eclipse.org/bugs/show_bug.cgi?id=100080
Current definitions of the APIs allow us to add this function in the Memory
View.
This item is not currently planned for 3.2 due to time and resource
limitation. If you would like to try to implement this, contributions are
always welcome! :)
Here's how I envision it to work:
1. We will need to add "export" and "import" actions in the table
rendering.
2. When the "Export" action is invoked, a dialog is displayed. The
dialog shows two things: address and length. The address field is
pre-filled with the current selected address from the rendering. User can
modify the address and the length. The dialog exports the memory with the
specified address and length and saves the values to a file. Note that we
are only saving the values. The file will not save the address nor the
attributes of each byte.
3. When the "Import" action is invoked, a dialog is displayed to allow
user to pick a file to import. The dialog will also ask for an address
where memory is going to be written to. The address field will be
pre-filled with the current selected address. Then the dialog reads the
values from the file and goes through the IMemoryBlockExtension interface
to write the values to memory. If the values can be written successfully,
the memory block should fire a content change event. The rendering
receives the event and refreshes.
Re: Memory Search
The Memory View has a "Go To Address..." action. This actions allows user
to go to any address within a memory block. This should fulfill your
requirement of an "Address" search.
I have opened the following enhancement request for the "value" search
feature:
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=118660>https://bugs.eclipse.org/bugs/show_bug.cgi?id=118660
This item is not planned for 3.2. I will only implement this if time
permits.
Re: Memory Mapped Registers
I have recently added tooltip support in table renderings. By default, the
tooltip shows the current address. Clients may override to show different
text in a tooltip. Would it be sufficient for you to show register values
in the Memory View?
(Embedded image moved to file: pic18730.jpg)
Re: Grey out unused Memory Space
The memory view does not have a notion of "Unused" memory. The Memory
View understands attributes defined in MemoryByte (readable, writeable,
endianess and whether the byte has history or not). Unused memory means
that the memory has not been initialized?
I do not think I will change the definition of MemoryByte to add the
"unused" attribute. I consider this to be a special case. I suggest that
you subclass from MemoryByte to add the "unused" attribute. You can
provide customized coloring to the rendering by providing an IColorProvider
in #getAdapter(...) from your memory block. If a memory block provides an
IColorProvider adapter, the rendering will consult the color provider when
it comes to decorating the rendering. You color provider can check for
this specialized "unused" attribute and grey out those cells accordingly.
Thanks...
Samantha
