[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] Re: Disassembly Presentation Discussion (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
