Certainly a challenge!
The other thing that I have had in the back of my mind is what we do
with the fact that in order to do disassembly correctly for some
processors you must have additional information beyond what you get from
the target alone (or from an image alone). For example, just from
looking at the target you may have no way of knowing address ranges that
are 16 bit instructions versus 32 bit instructions (only way to do it is
by looking at "carrier symbols" in the debug info). Or for a CISC
processor, perhaps you need to have some addresses of "labels"
(functions, or data objects) so that you can "resync" the disassembly so
that you get valid instructions. I am not sure how to incorporate this
kind of input into the disassembler, especially considering Johns point
about the location of different debuggers implementations of a
disassembler. Perhaps as a first pass the interface that provides
disassembly exposes some set of properties that can be set
programmatically? That way you could at least tell it "disassemble this
chunk of memory and assume that they are 16 bit instructions" or
whatever is applicable to a given architecture.
Aaron
-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Wednesday, May 31, 2006 6:20 AM
To: Device Debugging developer discussions; Device Debugging developer
discussions
Subject: RE: [dsdp-dd-dev] Disassembly View Requirement
I agree 100%. The challenge there will be in building that framework
and, just as important, building up a pool of components that we can all
share. In our environment, the smarts to do that sort of thing
(disassemble, parse symbolics) exists as C++ code in components that
plug into our debugger engine. For the model we've been discussing in
this thread, we'd need those capabilities to exist as Eclipse plugins.
And of course, it doesn't make sense for two companies to write, say, a
dwarf parser and ARM disassembler. So, we need some coordination to make
this happen.
The framework and its layers seems like a fairly large undertaking that
should probably be driven by a dedicated technology subgroup. It will
enable quite a number of other technologies.
John
At 09:57 PM 5/30/2006, Doug Schaefer wrote:
>I think we really have two different requirements. One is to view a
>block of memory as disassembly, or for that matter a block of object
>code stored in an executable. As well, we have the need to be able to
>see disassembly while stepping through code or sitting at a breakpoint.
>
>I don't see why we would need to pick a single solution to do both. I
>can see the need for integration within an editor and within a view. We
>can go for the gusto and do both. But it does point out, as Samantha
>said, for the need for a core framework to produce disassembly text
>from different sources for different purposes. We shouldn't have to
rely on the debugger to do it.
>
>I think doing the exercise of walking through different use cases and
>figuring out how Eclipse can best serve them is a prudent thing to do
>at this stage. It'll be easier to pick technologies if we understand
>and have documented what the user wants to do with them.
>
>Doug Schaefer, QNX Software Systems
>Eclipse CDT Project Lead, Tools PMC member http://cdtdoug.blogspot.com
>
>-----Original Message-----
>From: dsdp-dd-dev-bounces@xxxxxxxxxxx
>[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuong, Patrick
>Sent: Tuesday, May 30, 2006 6:05 PM
>To: Device Debugging developer discussions
>Subject: RE: [dsdp-dd-dev] Disassembly View Requirement
>
>John,
>
>We have two options to show mixed mode, and I don't have any strong
>opinion which way is better. They both have pros and cons. If I have a
>choice, than I think it will make more sense to have the current CDT
>disassembly window to show address base mixed mode and have the editor
>to show source base mixed mode :)
>
>Regards,
>Patrick
>
>-----Original Message-----
>From: dsdp-dd-dev-bounces@xxxxxxxxxxx
>[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
>Sent: Tuesday, May 30, 2006 6:01 PM
>To: Device Debugging developer discussions; Device Debugging developer
>discussions
>Subject: Re: [dsdp-dd-dev] Disassembly View Requirement
>
>For what it's worth, our commercial (non-Eclipse) product supports
>exactly what Samantha is describing. You can have the memory window
>display disassembly, or even source, and even mixed disassembly+source.
>
>Whether this is a hard requirement for us, that's a different story.
>I don't know how disappointed our existing users will be when they are
>unable to do the same in Eclipse. Certainly, of paramount importance is
>being able to disassemble an arbitrary block of memory.
>The rest seems like a usability issue.
>
>John
>
>
>At 04:40 PM 5/30/2006, Mikhail Khodjaiants wrote:
> >Samantha,
> >
> >>Showing disassembly in the Memory View was one of CDT's
requirements.
> >
> >The CDT requirement is showing memory as disassembly, not showing
> >disassembly in the Memory view. It can be implemented as an
> >additional memory rendering, but we have never thought of it as a
> >full replacement of the Disassembly view.
> >
> >Mikhail Khodjaiants
> >----- Original Message ----- From: "Samantha Chan"
> ><chanskw@xxxxxxxxxx>
> >To: "Device Debugging developer discussions"
> ><dsdp-dd-dev@xxxxxxxxxxx>
> >Sent: Tuesday, May 30, 2006 5:29 PM
> >Subject: RE: [dsdp-dd-dev] Disassembly View Requirement
> >
> >
> >>Hi -
> >>
> >>Re: R1 Generic Disassembly View
> >>Are we having a separate disassembly view? Or are we looking at
>displaying
> >>disassembly as a rendering in the Memory View? Showing disassembly
> >>in
>the
> >>Memory View was one of CDT's requirements.
> >>
> >>Re: Portable disassembly component
> >>One of the requirements is to make showing disassembly as a portable
> >>component and it can be "plugged" into any view or editor or
> >>anywhere
>we
> >>need it. e.g. the Modules View
> >>
> >>Re: Optimized code:
> >>I think there is another requirement for dealing with optimized
code.
>Kirt
> >>Beitz from Freescale indicated that they have cases where there is
> >>no
> >>1-to-1 mapping between instructions and source code either way.
> >>They
>need
> >>to be able to show disassembly and source side-by-side, not
>interlacing.
> >>They need to be able to highlight several non-contigous lines of
> >>instructions per source line... or highlight several non-contiguous
>lines
> >>of source lines per instruction.
> >>
> >>Re: Input to disassembly
> >>Does it make sense to add a requirement to allow this disassembly
>component
> >>to accept any input for creating the disassembly "view"? e.g. We
> >>have cases where it makes sense for the disassembly component to
>disassemble
> >>memory from a memory block and show it as disassembly instructions.
>In
> >>other cases, we can have a binary file as input and display its
>content as
> >>disassembly.
> >>
> >>Thanks...
> >>Samantha
> >>
> >>
> >>
> >>
> >> "Ewa Matejska"
> >> <Ewa.Matejska@pal
> >> msource.com>
>To
> >> Sent by: "Device Debugging developer
> >> dsdp-dd-dev-bounc discussions"
> >> es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>
> >>
>cc
> >>
> >> 05/30/2006 04:52
>Subject
> >> PM RE: [dsdp-dd-dev] Disassembly
>View
> >> Requirement
> >>
> >> Please respond to
> >> Device Debugging
> >> developer
> >> discussions
> >> <dsdp-dd-dev@ecli
> >> pse.org>
> >>
> >>
> >>
> >>
> >>
> >>
> >>Hi,
> >>
> >>The requirement of mixed mode/assembly/source toggle is also an
> >>Editor Subgroup requirement. We should coordinate and work together
on this.
> >>Some of the other requirements seem relevant to the Editor as well,
>such as
> >>the multiple breakpoint icons.
> >>
> >>Thanks,
> >>Ewa.
> >>
> >>From: dsdp-dd-dev-bounces@xxxxxxxxxxx
> >>[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuong,
> >>Patrick
> >>Sent: Tuesday, May 30, 2006 12:23 PM
> >>To: Device Debugging developer discussions
> >>Subject: [dsdp-dd-dev] Disassembly View Requirement
> >>
> >>Hi everyone,
> >>
> >>I have updated the disassembly twiki website with the requirements
>that I
> >>have gather through multiple email threads in the archive. Any
>feedback and
> >>additional requirement is welcome. Additionally, I suggest that we
>keep one
> >>discussion thread for the disassembly view requirement. This can be
>related
> >>to the CDT disassembly view or Disassembly renderer in the Memory
>view.
> >>
> >>Regards,
> >>Patrick_______________________________________________
> >>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
> >
> >_______________________________________________
> >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
>_______________________________________________
>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
_______________________________________________
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
