| RE: [cdt-dev] Re: [dsdp-dd-dev] Disassembly proposals |
Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;boundary="----_=_NextPart_001_01C863F2.6C676414"
Hi John,
Please, see my answers inline.
From: cdt-dev-bounces@xxxxxxxxxxx [ mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
Sent: Wednesday, January 30, 2008 10:36 PM
To: Device Debugging developer discussions; dsdp-dd-dev@xxxxxxxxxxx; cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Re: [dsdp-dd-dev] Disassembly proposals
Mikhail,
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 course).
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 not.
MK: Viewer reacts to user actions (scrolling, resizing, etc) and sends requests to the backend. It's up to the backend to provide content. Our 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
- interleaved source+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.
This 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 backend.
I don't think it's a problem to implement your requirements for the CDI based backends, assuming the backends provide the corresponding functionality.
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.
John
At 08:17 AM 12/13/2007, Mikhail Khodjaiants wrote:
Content-Class: urn:content-classes:message
Content-Type: multipart/alternative;boundary="----_=_NextPart_001_01C83D92.D5867888"
Hi,
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 possible.
Regards,
Mikhail Khodjaiants
ARM Limited
--
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.
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
--
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.
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
--
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.