Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dsdp-dd-dev] Disassembly View Requirement 
Duane,
Much of what you mentioned is possible today thanks to the design of pluggable renderings in the Memory view. Someone today can develop a rendering which shows a memory block as a zip file, an image or whatever.
What we've been discussing, among other things, is a rendering which shows disassembly, and hopefully mixed disassembly/source. The challenge is that the conversion from bytes to this type of representation is something that would be useful across many different views. As such, we're been discussing how to approach this so that the conversion logic is written and maintained in one place, not many. 

John


At 09:32 AM 6/1/2006, Duane Ellis wrote:

My $0.02...

This gets complicated very fast.

==================================================

A system may have multiple targets ... some
think of DUAL CORE as two of the same CPU execution
units. That's not always the case. An example is an
ARM + some onchip DSP - TI makes such a chip.

        Search google for:  "TMS320DM64x DSPs"

TI is not alone, www.arm.com has TEAK and OAK dsps.

==================================================

I would view this feature like this:

The default memory view is a byte dump.

The memory view window probably needs a means to
respond to something like a "right-click - force
some action at this byte location" command.

The "force" option might be "format specific"

For example:
        Force - this byte as the 1st byte of an opcode
        Toggle: Big-v-Little Endian
        Force - ARM not THUMB opcodes starting here.

==================================================

Above, I used the example of different disassemblers
such as a DSP vrs ARM opcodes.. That is not always
the case... these are other examples:

Think of this as a "View as..." selection from the
memory view window.

A hiearchy with [+] to-expand-buttons

For example -
        a JAVA jar file is really a ZIP file
        a MP3 file has frame headers + data
        Some MP3 headers are ID3 tags...

Another example of this is REGISTERs on a chip.
        For example ATMEL AT91RM9200 - has many IO
        devices on chip, serial ports, IRQ controller
        USB, GPIO pins, and the like.

        Being able to click & see configuration
        registers explained in english is nice...

Other non-chip things could be plugged into the view.
There are some very generic ones such as:

        In-memory view of an ethernet packet
        a 'fly-by-wire' protocol for airplanes
        GSM frame packet {if there is such a thing}
        a BMP or JPEG file viewer.
        An image dump/view from a camera chip.

One should also be able to specify that a specific
byte is the 1st byte of a "C/C++" structure used
in their program.

There are also "vendor specific" formats.

   In our case, we create electronic books.
   The data we point at might be an ebook
   specific compression format... with a
   header and data... etc.

I'm sure the guys at Symbian & Nokia have their
formats also.

==================================================

While the above may be nice... a primary rule is
the "memory-view-plugin" needs to be robust.

Often times the data you point at is utterly wrong.
Think of choosing "View as Windows BMP" when the
data is actually random gibberish.

Also a "Dereference this as a pointer to..."

Remember: This is a debugger. Perhaps the bug is
the data in the BMP header your program is trying
to display - let us not crash the debugger.

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

Back to the top