[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cdt-dev] Re: [dsdp-dd-dev] Disassembly proposals
- From: "Mikhail Khodjaiants" <Mikhail.Khodjaiants@xxxxxxx>
- Date: Thu, 31 Jan 2008 10:17:02 -0000
- Delivered-to: firstname.lastname@example.org
- Thread-index: AchjkKwrTsGaod95S72EHbCTNPuMewAXkKTQ
- Thread-topic: [cdt-dev] Re: [dsdp-dd-dev] Disassembly proposals
Please, see my answers inline.
I apologize for the delayed feedback. The proposal looks
like a great foundation. I would like to throw a bunch of ideas on the table and
volunteer to collaborate with you on this feature in order to make these
additional requirements a reality (where technically feasible, of
1. If would be nice if disassembly based on a frame context
would not limit itself to just code associated with that frame. Of course, the
PC would be the starting point and focus of the initial disassembly, but we'd
like to let the user scroll up and down the memory space as much as he wants.
It's up to the client to do it's best to find valid boundary lines for
disassembly. I'm not familiar enough with editors to know if this is possible or
MK: Viewer reacts to user actions (scrolling, resizing, etc) and
sends requests to the backend. It's up to the backend to provide
implementation supports infinite scrolling and I am planning to support it
for the CDI based backends.
2. We would like the user to be able to easily switch via (e.g., a
toolbar) how the content in the disassembly viewer is presented
- pure disassembly
- pure source
When showing pure source (and even
interleaved), the editor part is not showing the contents of a file per se, but
parts of files. For example, at address 0x1000 there might be code from foo.cpp,
at 0x1200 there might be code from bar.cpp. The disassembly view would show the
source statements for both, with some marker at the boundary points which
indicate the source file context for the lines that follow.
multi-mode presentation capability would be available in both the "editor" part
and the memory rendering.
MK: The content provided by the backend can be pure disassembly,
mixed source and disassembly or anything else. The content request
includes an object that passes presentation options to the
don't think it's a problem to implement your requirements for the CDI based
backends, assuming the backends provide the corresponding
3. Clients should be able to contribute custom markers. For example, in
addition to setting standard breakpoints, the user should be able to set product
specific trace points.
MK: Clients contribute annotations via annotation
providers. At the moment our implementation sets the standard CDT
breakpoints and instruction pointers. The problem I see for the CDI based backends is that the only one
adapter can be registered.
Let me know what you think of these ideas and if you
would be willing to co-develop this feature.
08:17 AM 12/13/2007, Mikhail Khodjaiants wrote:
I have updated the wiki page (
http://wiki.eclipse.org/DSDP/DD/DisassemblyView) and added the proposals
for the disassembly window management which is the simple part of the task.
Please, feel free to add your comments.
Currently I am working on the
document that describes the viewer proposals and trying to prototype it at the
same time (or vice versa I should say). I'll try to post it as soon as
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.