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

[Adam Finucane <adam@xxxxxxxxxx>]

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.

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.

Another issue that came up is that the memory view aways assumes byte 
addressable memory. That is not always the case. Some memory spaces are word 
addressable. For our implementation the user has to double the actual address 
they want to when specifying the address to monitor.

Adam

HI-TECH Software



On Friday 28 October 2005 06:38, John Cortell wrote:
> Samantha,
>
> Several weeks ago, I submitted a proposal and draft implementation to
> Mikhail for address space support in the platform and CDT. It included
> changes required in the Memory Window code. Like your proposal, the string
> representation of an address was left to the debugger back-end. So it could
> be "<space>+<addr>", or "<space>+<addr>", or whatever.
>
> As for issues you've brought up, here are my assumptions:
>
> - Scrolling starts and stops at the boundary of the address space. I don't
> expect there to be a need to scroll into a different address space. I'm not
> even sure that would make a lot of sense.
>
> - A memory block represents one and only one address space. So BigInteger
> attributes/parameters are fine in the context of a block object.
>
> I did not consider the "Go to address" action. Here's what seems intuitive
> to me: the action should be in the context of the block the action was
> initiated from. If the user enters an address that has no space qualifier,
> then the space of the request is implicitly the block's space. If the user
> specifies a space qualifier, then the action should fail if it specifies a
> space that is not the same as the block's. Bringing up a new block doesn't
> seem like the right thing to do--not to me, anyway.
>
> The determination of whether the go-to-address is in the right context
> would be done by the debugger back-end, so there would have to be some new
> interaction between the mem window code and it. Again, as I did not
> consider that in my proposal and draft implementation, I don't have any
> detailed description of what that interaction could be.
>
> Regarding specifics of my proposal, I will "officially" submit the proposal
> in the next few days. I previously submitted in an informal way. I will
> create a bugzilla report and create a patch file. Unfortunately, I don't
> have those files with me today, and I also have not delved into getting
> sources from the eclipse.org cvs server (which I learned is necessary to
> create a patch file). So, there's some work I need to do on my end, but
> hopefully you will have my proposal soon. It includes what I saw as
> required changes to a few memory window interfaces--some things that are
> taking a simple BigInteger but require an additional addr-space parameter.
> If you find a better solution, I'm all for it.
>
> The proposal includes some temp changes you can apply to CDT to rig the
> debugger into some minimal address space simulation, so that you actually
> have some sort of working test-case to experiment with.
>
> John
>
> >-----Original Message-----
> >From: cdt-debug-dev-bounces@xxxxxxxxxxx
> >[<mailto:cdt-debug-dev-bounces@xxxxxxxxxxx>mailto:cdt-debug-dev-bounces@ec
> >lipse.org] On Behalf Of Samantha Chan
> >Sent: Thursday, October 27, 2005 11:21 AM
> >To: cdt-debug-dev@xxxxxxxxxxx
> >Subject: [cdt-debug-dev] Need feedback for support of multiple
> >addressspaces in Memory View
> >
> >
> >Hi -
> >
> >I'd like to gather some requirements about supporting multiple address
> >spaces in the Memory View.  Here's how I think the Memory View should work
> >in a multiple address space environment.  Since I am not familiar with
> >such environment, it would be great if you could give me some feedback.
> >
> >Adding Memory Monitor
> >In a multiple address  space environment, when adding a memory monitor to
> >the Memory View, user will enter "<address space identifier> " +
> >"<address>" as the expression to monitor.  How the user should enter this
> >expression is platform specific and it's up to the debug adapter to define
> >how user should enter this.  The important thing here is that user will
> >enter a string for the debug adapter to evaluate.  Currently, the Memory
> >View does not parse this expression when it is entered.  The view simply
> >passes the expression to the debug adapter and expects client to return a
> >memory block.  In this case, clients is supposed to evaluate the
> >expression, taking address space into account, and return a
> >correct  memory block to the view for display.  I think the current
> >implementation already supports adding memory block with multiple address
> >spaces. Let me know if you need anything else in this area.
> >
> >Scrolling
> >After the memory block is added to the view, user could scroll up at the
> >down the view until it hits the memory block boundary.  The boundary is
> >defined by the start and end addresses specified in the memory block.
> >
> >(IMemoryBlockExtension)  The start and end addresses are represented by a
> >BigInteger.  In the case of a multiple address space environment, clients
> >may define the boundary that is suitable for the address space that the
> >memory block is located in.  When the user scroll up and down of the
> >memory monitor, the user can only go within the boundary of the address
> >space. Is this what your user would expect?  Would there be cases where
> >the user would require to cross address space boundary within a single
> >memory block? (i.e. can the user scroll to a different address space when
> >they are looking at a memory monitor?  How would the memory block change
> >as the user steps into another address space in this case?  i.e.  What
> >happens to the addressing in the memory block?  Is the memory block going
> >to have mixed properties as the user crosses the boundary?)
> >
> >Go To Address Action
> >There is an action in the Memory View to allow user to jump to any address
> >in a memory block.  This is an area where enhancements should be made in
> >
> >order to support multiple address spaces.   When this action is invoked,
> >the action asks the user for an address to go to.  The action tries to
> >convert the string entered to a BigInteger.  If the conversion fails, the
> >action pops up an error message.  If the conversion succeeds, the action
> >tells the rendering to position itself to the specified address.  If the
> >address is outside of the boundary of the memory block, the action asks
> >the debug target to evaluate the address and return a new memory block,
> >assuming that the debug target may be able to create another memory block
> >that is outside of the current boundary.  If this fails, then the action
> >will also pop up an error message.
> >
> >In the case of multiple-address space, the user may enter an expression
> >with an address space identifier when using the "Go To Address" action.
> >(For example, the user could enter AddressSpaceId2:0x123456 as the
> >
> >expression.)  In this case, conversion of this expression to a BigInteger
> >will fail, and user will never be able to go to the specified location.
> >The desired behavior in this case is that the action should not try to
> >convert the expression to a BigInteger.  Instead, the action should ask
> >the debug target to evaluate the expression entered.  The debug target
> >should return a valid address  if the expression can be evaluated to an
> >address in the same address space as the memory block that the user is
> >looking at.  My question here is that what happens if the expression is
> >evaluated to an address of another address space?  Would  your user tries
> >to go to an address from another address space when looking at one memory
> >monitor?  If so, would you expect the view to create a new memory monitor
> >showing the other address space?  Or would you expect the current memory
> >monitor to switch to the new address space?
> >
> >These are the things that I can think when dealing with multiple address
> >spaces environment.  If there is anything else you can think of, please
> >let me know.
> >
> >Thanks...
> >
> >Samantha
> >
> >_______________________________________________
> >cdt-debug-dev mailing list
> >cdt-debug-dev@xxxxxxxxxxx
> ><https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev>https://dev.eclips
> >e.org/mailman/listinfo/cdt-debug-dev
>
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev