[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-debug-dev] Need feedback for support of multiple address spaces in Memory View
|
Comments inline...
At 04:43 PM 10/27/2005, Adam Finucane wrote:
Hello,
We were able implemented a java debugger (simulator) with multiple memory
spaces in CDT 2.1.1. So the debugger isn't to far off being multiple memory
space compatible. Having an address object that contains both the memory
space id and the address would make our lives easier. I think this was in
John's proposal.
In my proposal, the debugger backend provides an IAddressFactory (a CDT
construct). With this approach, the actual representation of an address is
hidden from CDT. For example, one debugger implementer may choose to use a
character storage representation for the space; another might use a string;
a third might use a integral value. Ultimately, it doesn't matter to CDT.
The key is that the backend's IAddress implementation can encode/decode the
internal representation to/from a string representation.
Where this breaks down is in the platform. Again, IAddressFactory/IAddress
is a CDT thing; the memory window, e.g., knows nothing about it. Ideally,
the platform would provide an abstract representation of an address, but I
imagine that would be pretty costly to do at this point. So, in some
platform interfaces, I found I had no choice but to pick a representation
(String) for the space qualifier and add it to the method signatures.
We use the "<space>:<address>" syntax to specify the starting address of the
memory space monitor. The problem with this syntax is there is no way to know
what the magical word for "space" is. There is no indication in the user
interface as to what the space could possible be, or even if there is more
than one memory space available to view.
I think that a combo box could be used to specify a list of memory spaces
available for selection to the user. The list memory space names that are
available can be provided by the Target. If there is only one memory space
the combo can just not be added.
My thoughts there is that there would be a (DSDP) view that would let the
user see a list of available address spaces for the debug session. The
debugger back-end might populate that, perhaps with info from the binary
parser, or from the target. My point here is that I don't think cluttering
the memory window with a new control is worth while. There may be other
views where the user might find himself asking "What are the available
spaces?". Having a central location for that info seems best to me.
John
