| Re: [cdt-debug-dev] Need feedback for support of multiple address spaces in Memory View |
Hi -
Thanks for all the feedback. They are really helpful.
Re: Address Spaces and Adding Memory Block
To allow user to enter an address space while creating a memory monitor, I
think the Memory View needs to be more flexible. Each debug target has
different requirements regarding how a memory block is created. Some debug
target requires the user to enter an address space id, while others may
require their user to enter the size of an addressable unit. Currently,
the dialog that prompts the user for entering this information is static.
There is no way for a client to customize this dialog and ask user for
information other than the expression to monitor. This needs to be more
flexible to allow clients to prompt user for other information.
Re: Go To Address
As for supporting multiple address spaces with the "Go To Address" action,
currently, there is no API to allow the platform to evaluate an expression
to an address. But I agree that the platform should not parse the
expression and should ask the debug target to evaluate the expression. I
will investigate and see what I can do in this area.
Re: Byte Addressable Memory
The memory view does not assume byte addressable memory. It supports
addressable units bigger than one byte. Make sure you implement
IMemoryblockExtension in your memory block. That interface has a method
called #getAddressableSize(). Make sure you return the correct addressable
unit size in this method. If you are still having problem with it, please
let me know.
Thanks...
Samantha
Mattias
Bertilsson
<matb@xxxxxxx> To
Sent by: CDT Debug developers list
cdt-debug-dev-bou <cdt-debug-dev@xxxxxxxxxxx>
nces@xxxxxxxxxxx cc
Subject
10/28/2005 04:12 Re: [cdt-debug-dev] Need feedback
AM for support of multiple address
spaces in Memory View
Please respond to
CDT Debug
developers list
Here is my two cents, take it or leave it...
Both as a CDT user and as a plugin developer I like Adam's suggestion
better. I think address space id:s and address values are two different
things. For instance, I think the user will change addresses much more
often than he will change address space id:s.
Why define a special syntax just to be able to put them in the same text
field?
If we want some more intuitive way to select address space, isn't that a
reason in itself to keep the address space id out of the address text
field?
/Mattias Bertilsson
Adam Finucane wrote:
Comments inline...
On Friday 28 October 2005 09:59, John Cortell wrote:
Comments inline...
At 04:43 PM 10/27/2005, Adam Finucane wrote:
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
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
(See attached file: matb.vcf)
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
Attachment:
matb.vcf
Description: Binary data