Re: [cdt-debug-dev] Need feedback for support of multiple address spaces

[Adam Finucane <adam@xxxxxxxxxx>]

Comments inline...

On Friday 28 October 2005 09:59, John Cortell wrote:
> 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.

The problem in the 2.1.1 CDT implementation which doesn't allow the proposal 
above to be used is with the createAddress(BigInteger) method of the 
IAddressFactory. Memory space information is lost when this method is used. 
My opinion is that it should be removed. This may have changed in the new 
3.x.x release, please correct me if I'm wrong.

Here is the example that identifies the problem above. A string is given to 
the ICDITarget, from the string a memory space and and address can be 
extracted. A ICDIMemoryBlock is then created. The memory block has a method 
called getStartAddress() which returns a BigInteger. I think it is the 
CFormattedMemoryBlock where the the BigInteger address is passed to the 
ICDITarget to create the IAddress using the IAddressFactory. By this time the 
memory space information associated with the address has been lost, so the 
IAddress implementation selected is always the same memory space. If 
ICDIMemoryBlock returns an IAddress the problem no longer exists.

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

I think we both agree that a list of available memory spaces needs to be 
provided to the user. We are in a disagreement about how they are presented 
and how the user should enter the memory spaces when it is required. Could I 
suggest that you allow the UI to be customizable enough, from a developers 
point of view, so a preferred solution can be implemented by third parties.

Adam