[dsdp-dd-dev] Need feedback for support of multiple address spaces in Me

[Samantha Chan <chanskw@xxxxxxxxxx>]

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