[
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
|
Samantha,
Let's see if Ted wants ownership of this. If not, you can assign it to me.
Regarding verification: let's further consider the Memory view. I
would imagine that after the user modifies a set of bytes in a
rendering, the view asks for an update of the memory and doesn't
assume the content of the memory is what it was plus the
modifications. If there was a disconnect (bug) between the UI and
writing of the memory, we'd want the user to be able to see that. For
example, imagine somewhere along the way, a memory view modification
request is mishandled and memory is written in the wrong endianness.
We'd want the memory view to truly reflect what's on the target, not
what the upper levels of the debugger expect it to be. So, to that
extent, there's a "visual/manual" verification in place. If the user
types a modification and see something different after he hits
<enter>, something is up...Whether that's how the memory view
currently works or not, I don't know.
With a bulk write (import or fill), that manual verification isn't as
feasible. The user might do the operation without even having a
memory window open. So, to be 100% sure the import operation has left
the memory as specified in the exported file, the user may want to
optionally enable verification. It's certainly a performance hit, but
if the verification is optional, that seems ok to me.
Just a thought. It's not a critical piece of the feature, but a
"nice-to-have". I've seen Flash Programmer with this feature, so
there is some precedent.
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.
John
At 10:04 AM 4/4/2006, Samantha Chan wrote:
Hi -
That's the first time I have seen people fighting for work! :)
Re: reading / writing on a job.
I agree. Any interaction with the memory block should be done on a job to
avoid blocking the UI thread.
Re: verify option
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. For example, when the user modifies
memory using a memory rendering, UI does not try to verify memory after
modification. Would catching DebugException from the memory block be
enough? (IMemoryBlockExtension#setValues(...) throws DebugException if
there is an error.)
In addition, I imagine that the verification will be done by the action /
dialog that's doing the import. Since we do not want to hold up the UI
thread during verification, the verification will be done on a job. If
verification fails some time later, how are we going to report the error?
Popping up an error dialog some time after the import operation could be
annoying if the user is already doing something else.
Re: CopyToClipboardAction
I don't think reusing CopyTableRenderingToClipboard action is going to work
very well. The action goes through the rendering to ask for its content
and put it onto the clipboard. In an export operation, we are exporting
raw memory. We don't want the exported content to be rendered in any way.
Otherwise, the import operation will be complex to write. The import
operation has to know how memory was previously rendered and exported in
order to decode the file and write it back to a memory block again. I
think both the import / export actions should be done independent of any
rendering. They should only talk directly to a memory block.
Re: Support for expression in the import / export dialog
It would be useful if the user wants to export / import a chunk of memory
from a register / variable. User can simply enter a register name /
variable name during an import / export. Since the actions are
retargettable, clients can override that action to provide customized
dialog to support expression evaluation.
Would it help if I assign this feature to one of you so that others know
that you are working on this feature?
Thanks...
Samantha
John Cortell
<john.cortell@fre
escale.com> To
Sent by: "Williams, Ted"
dsdp-dd-dev-bounc <ted.williams@xxxxxxxxxxxxx>,
es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>
cc
04/04/2006 12:30 Subject
AM [dsdp-dd-dev] Re: FW:
Load/save/fill memory operations
Please respond to
Device Debugging
developer
discussions
Ted,
I'll be more than happy to yield this feature to you :-) I've got a million
other things to do, so I have no problem letting this one go. This is a
must-have feature for our first Eclipse based product, and that's why I was
going to jump on it. If you were planning on contributing this anytime in
the next six months or so, that would work for us. And of course, I'll be
more than happy to work with you on the feature if you'd like to team up on
it.
See my comments inlined below:
At 09:36 PM 4/3/2006, Williams, Ted wrote:
John,
Yes, I've been planning to contribute such a feature, but (oops) I
wasn't aware of the bugzilla. If you're planning to implement this
soon,
I'll hold off. :-)
I understand the feature will be extensible, but I'd like to add a
few
thoughts in addition to what I see in the bugzilla.
- The reading/writing should happen on a Job. Large chunks can take
substantial time to transfer to and from embedded targets. The cancel
flag should be checked periodically, between read and write requests.
Definitely.
- Would a verify option (checkbox in the dialog, read and compare
after
write during the download) be useful?
Sure.
- There may be some overlap with the "copy to clipboard" action.
Maybe
copy and paste could be shortcuts to import/export actions or at
least
some of the code could be reused? Export to textual is similar to
copy.
Indeed, there's overlap, but I'm not sure there will be a good mapping
between copy&paste and the actions. If we can think of copy&paste as an
import/export action with a fixed, pre-defined set of parameters...but even
there, the destinations are quite different. I imagine there's potential
for code reuse but not a direct link between the two sets of actions.
- Any thoughts on supporting expressions in the address field of the
import/export dialog?
I think Samantha and I were envisioning import/export being retargetable
actions that could be invoked from, say, the context menu of the variable
view and expression. To that extent, expressions would be supported, but
such an action would bring up the dialog with the physical ptr/variable
value/address as the start address, pre-populated in the dialog. Whether we
should directly support expressions in the dialog...I suppose, but I don't
see a pressing need for it.
John_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
