[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] Disassembly View Requirement
|
Hi folks,
Following up on what Pawel said, we're still going through internal
sign-offs on our contributions. I am hoping to have that completed in a
couple of weeks, and then it's on to Eclipse IP due diligence.
Meanwhile, Pawel and Ted and working on our debug model contributions in
an internal CVS repository.
Doug G
> -----Original Message-----
> From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
> Sent: Wednesday, May 31, 2006 3:00 PM
> To: Device Debugging developer discussions
> 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
