[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] Re: FW: Load/save/fill memory operations
|
Hi -
Re: Verification
I agree with John that if the Memory View is not opened, the user has no
way of verifying the imported data. In that case, automatic verification
is needed. I suggest that verification be done similar to how building the
workspace is presented to the user. The import dialog has an option to
allow user to verify data after the import. During the import /
verification operation, the UI should pop up a progress dialog to show
progress. The import operation cannot be cancelled. (We don't want the
import operation to be half done and leave the system in an usable state.)
But the verification process can be cancelled using the progress dialog.
User should also have an option to run the verification progress on
background. This will dismiss the progress dialog and move it to the
progress bar at the bottom right corner of the workbench. If verification
failed, then an error message should be displayed.
I also suggest that the verification operation be retargettable. By
default, the import action provided will do verification by asking for
memory from the memory block again and verifying it with the data from the
imported file. However, clients should have an option not allow for
verification. In addition, if verification is to be done at a lower lever,
e.g. by the debug engine on write or some other more efficient way, clients
should have a way to override the verification methods. There is no way to
pass a verify flag to the back-end using
IMemoryBlockExtension#setValues(...). However, I expect that the verify
option will be a global preference. In this case, a debug adapter may
query for this preference and pass this information to its engine
internally.
Re: Address Space Support in Import/Export
John> I think Samantha's solution to that was
> to allow debugger providers to provide a custom dialog for accepting
> the address from the user. We may want to take the same approach for
> the import/export feature.
Correct. Because the actions are retargettable, clients can provide
customized dialog to show address space information. The base
actions/dialogs would only accept address for import / export. For
expression/address space support, clients need to override the base
actions/dialogs.
Re: Context Menus and the views
John> However, let's first consider the various ways in which that feature
> will work. I strongly believe it shouldn't be tied to the memory
> view. I should be able to right click on a ptr variable in the
> Variables view and choose an import/export memu item which will bring
> up the import/export dialog with the value of the ptr variable
> pre-populated in the dialog.
Yes, I agree.
Re: Find Feature
There is an enhancement request for this.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=118660
Thanks...
Samantha
John Cortell
<john.cortell@fre
escale.com> To
"Williams, Ted"
04/05/2006 05:47 <ted.williams@xxxxxxxxxxxxx>,
PM Samantha Chan/Toronto/IBM@IBMCA,
"Device Debugging developer
discussions"
<dsdp-dd-dev@xxxxxxxxxxx>
cc
Subject
RE: [dsdp-dd-dev] Re: FW:
Load/save/fill memory operations
At 04:22 PM 4/5/2006, Williams, Ted wrote:
>Samantha> "My concern here is performance. Writing and reading memory
>could take a long time. I am not sure if verifying the write operation
>to a memory block should be an UI's responsibility."
>
>Agreed, it probably shouldn't be the UI's responsibility to actually
>perform the verify (write, read, compare). Any ideas on how to pass a
>verify flag to the back end? It's unfortunate that
>IMemoryBlockExtension.setValue takes a byte array; a MemoryByte array
>would cleanly allow for a VERIFY_ON_WRITE attribute.
If the idea is to perform write verifications at lower levels, there
could be a debugger global state which dictates this behavior across
all write operations. Our commercial non-Eclipse product has this feature.
>John> "Regarding the expression support, one thing that springs to mind
>is the need to support address space. We'll need to keep that in mind
>when designing the feature."
>
>I've been wondering about address spaces, too. Should the import/export
>dialogs contain UI for selecting the address space? Or should the
>operation use the selected IMemoryBlock and assume it was created with
>the desired address space? I think this fails when the user modifies the
>address field in the dialog.
The argument has been made that the memory view should have an
address space selection, and I think Samantha's solution to that was
to allow debugger providers to provide a custom dialog for accepting
the address from the user. We may want to take the same approach for
the import/export feature.
However, let's first consider the various ways in which that feature
will work. I strongly believe it shouldn't be tied to the memory
view. I should be able to right click on a ptr variable in the
Variables view and choose an import/export memu item which will bring
up the import/export dialog with the value of the ptr variable
pre-populated in the dialog.
Bringing up the import/export dialog from the memory view should
follow the path you suggested...use the IMemoryBlock's address space.
>Has there been any discussion on memory "find"? When necessary,
>searching for memory (up/down, literal/regex) can be quite valuable.
This would be very useful. I suppose this capability is technically
provided by the export feature (you could export then grep), but
that's awfully cumbersome.
>John> "Let's see if Ted wants ownership of this. If not, you can assign
>it to me."
>
>I'd be happy to provide the initial implementation, but I'll count on
>John to provide feedback. :)
You can count on it :-)
John
