John,
> Another option for the sort of thing you're talking about is to
introduce a feature in the binary parser and perhaps expose that via the modules
view.
Glad to hear it, I have been thinking on this feature for a long
time.
> I see a
pluggable component that disassembles a block of bytes into disassembly plus a
mapping of disassembled statements to source lines. The component
> would then
be used in the memory view and the modules view (?), editor (?), or anywhere
else we need that functionality.
+1 though the presentation issues remain
open
Mikhail
----- Original Message -----
Sent: Thursday, May 25, 2006 10:27
AM
Subject: Re: [dsdp-dd-dev] Re:
Disassembly PresentationDiscussion (formerly Memory View discussion) (Samantha
Chan)
At 09:10 AM 5/25/2006, Chris Recoskie wrote:
>2. We don't want the memory
view to show disassembly from image code. >What we've been talking
about is taking what the target reports as being memory, and showing it
not as a series of memory units but as disassembly.
I think there is
also a use case for viewing the disassembled contents of the binary file
that is loaded on to the target system. In those cases where you
are, as Duane says, stomping all over your opcodes, it would be nice to
be able to compare memory to the golden image from the
original file. Or in general, users will find it easier to just
open up the binary and have it disassembled for them rather than hunting
in the build options to see how to get their compiler to spit out a
disassembly listing. Our commercial non-Eclipse product allows
you to right click on a source file in a project and choose 'disassemble' to
produce what your last sentence refers to. This in theory is no different than
disassembling from the image itself. There's no need to hunt for options or
make any setting changes with this approach. We plan to port this feature to
our Eclipse based product and most likely will contribute it to
CDT.
Another option for the sort of thing you're talking about is to
introduce a feature in the binary parser and perhaps expose that via the
modules view. Hopefully the parser and the debugger back-end would use the
same service to take a block of bytes and disassemble it.
And something
I didn't mention, but I thought was implicit, is that when disassembling from
memory, the debugger needs to make sure it adjusts for any opcodes it
changed in order to set breakpoints.
I think this provides further
justification for a separate disassembly editor/view in additon to a
disassembly memory rendering, as conceptually you would not be rendering
real memory. Although, you could argue that based upon the info in
the file, you might want to actually render the disassembly as it would
appear when loaded in memory, with actual addresses next to each line
etc. Or, perhaps you don't and all you want to do is render it with
labels, opcodes, and operands. Seems reasonable to me. I see a
pluggable component that disassembles a block of bytes into disassembly plus a
mapping of disassembled statements to source lines. The component would then
be used in the memory view and the modules view (?), editor (?), or anywhere
else we need that functionality.
John
John
_______________________________________________ dsdp-dd-dev mailing
list dsdp-dd-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|