[
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)
|
>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.
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.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
John Cortell
<john.cortell@fre
escale.com> To
Sent by: Device Debugging developer
dsdp-dd-dev-bounc discussions
es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>,
dsdp-dd-dev@xxxxxxxxxxx
cc
25/05/2006 09:54
AM Subject
Re: [dsdp-dd-dev] Re: Disassembly
Presentation Discussion (formerly
Please respond to Memory View discussion) (Samantha
Device Debugging Chan)
developer
discussions
<dsdp-dd-dev@ecli
pse.org>
Duane, it seems to me you're making two points.
1. The issue of forcing a memory view to synch up with what's on the
target.
This is really a separate issue from the memview-disassembler topic of this
thread. This is no more a concern for showing memory as disassembly as it
is for showing it as bytes.
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.
So, your request is implicitly in synch with what this feature is about.
This feature would not end up asking gdb (through CDT) to disassemble the
function "foo", but to produce disassembly from the memory at address
0x12345678 (which could be the func entry point of "foo"). As such, the gdb
behavior you described would not come into play.
John
At 08:29 AM 5/25/2006, Duane Ellis wrote:
Samantha,
I've been "lurking" on the memory view discussion for a while
and thought I would add a comment.
samantha> * The user is looking at some memory where their program is
loaded and
samantha> executed. They may be interested in knowing what the
disassembly
samantha> representation looks like. In that case, they may be
working in
a memory
samantha> block and wants to generate a disassembly rendering from
it.
I would add that there are *MANY* other cases when debugging embedded
systems you need to *FORCE* a memory view from the target device, not
something you have cached locally or can generate locally.
For example:
You have a bank switch type memory system, you need to *FORCE* the
memory
view to reload the memory block it is displaying - because - for
example
the hardware has changed the current memory view.
->> Banks switch could also be "virtual memory system" and are
looking
at pages that are mapped into memory.
Or - for example - you are debugging a target image, and your program
has done something really bad and written garbage all over your
opcodes.
GDB for example tends to use the EXECUTABLE file for memory contents
rather then "memory" when disassembling memory areas. Put it another
way
if your code is in an ELF file, ... If GDB can get it from a
elf-file,
it will get it from the elf-file, not read bytes from the target
memory".
In an embedded world - this can be very problematic.
Duane Ellis
Principal Engineer
Franklin Electronic Publishers
One Franklin Plaza
Burlington NJ 08016
email: duane_ellis@xxxxxxxxxxxx
voice: 1-609-386-2500 x4918
skype: duane_ellis
_______________________________________________
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
