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 
Pawel,
The ideal solution for the disassembly view is to make as flexible as the Variables or Debug view. I don't know if it's possible to use something like content and label adapters, or some new adapter types and at the same time support all requirements presented by Patrick. But it's worth to try to separate the view completely from any underlying model. 

Mikhail
----- Original Message ----- From: "Pawel Piech" <pawel.piech@xxxxxxxxxxxxx> 
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Wednesday, May 31, 2006 2:59 PM
Subject: Re: [dsdp-dd-dev] Disassembly View Requirement
Perhaps this should be treated as two separate discussions. 1) The disassembly view itself and the disassembler interface. 
2) A set of services that can be used to implement the disassembler.
For #2, the services need to be layered in such a way that it is possible to replace a lower level service with an custom implementation, but still be able take advantage of a higher-level services which are accessed directly by the view. This is indeed a challenging task, but hopefully with so much diverse experience in this group, it will be easier than we all think. Also, at the base of what we are planning to contribute to DSDP from our commercial product is a framework for managing layered services, which tries to address exactly this kind of design problem. 

Cheers
Pawel

Chuong, Patrick wrote:

On some of our device, the size of the opCode can be from 1 byte to 40+
bytes. Sometime there is no way that we can know the start address for
each opCode is valid or not unless there is symbol nearby. There is one
requirement that I request is to have some kind of indication (visual
feedback) to the user that the disassembled block might not be correct.

Regards,
Patrick

-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
Sent: Wednesday, May 31, 2006 12:52 PM
To: Device Debugging developer discussions
Subject: RE: [dsdp-dd-dev] Disassembly View Requirement

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
_______________________________________________
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

Back to the top