[
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
|
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@xxxxxxxxxxx]
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.eclipse.org/mailman/listinfo/cdt-debug-dev
