Re: [dsdp-dd-dev] Re: Disassembly Presentation Discussion (formerly Memo

[John Cortell <john.cortell@xxxxxxxxxxxxx>]

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