From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On
Behalf Of Pawel Piech
Sent: Friday, July 27, 2007 1:02
PM
To: Device Debugging developer
discussions
Subject: Re: [dsdp-dd-dev] Windows
Debugger
Hi Doug,
This is great news :-) I would love to hear your insights and comments on
DSF and I'll be happy to help you along as much as I can. Based on what
you said I think you have two choices for the windows debugger implementation:
1) You could copy the reference implementation and start refactoring the
commands so they match your protocol, or
2) You could try to re-use the reference implementation services, and try to
write a compatibility layer for your protocol.
Option 1 is the proper choice, but on the down side the reference
implementation and the APIs are evolving fast with three active contributors
from Ericsson, so you may find yourself spending a lot of time just keeping
current. Option 2 it probably sess work, but is not a good long term
solution because inevitably there will be differences between windows debugger
and gdb not just in command syntax but in behavior, which will require changes
in the service implementations. In either case though, you'll have a much
better feel for what's involved once you start looking at how the MI
implementation works.
As far as CDT compatibility, as far as I know there shouldn't be any major
problems between CDI and DSF. Here are the areas of integration as far as
I know them:
Launch
Debuggers based on DSF will need to implement their
own custom launches. Current CDT launches are heavily based on the CDI
implementation and cannot be shared. Although, the current DSF reference
implementation does re-use parts of the CDT launch UI, it is just a a temporary
solution.
Breakpoints
DSF can re-use CDT model breakpoints as is. Bug
183397 refers to integrating breakpoints from different debug models, which is
an issue for our commercial product and for long term extendability of CDT, but
it is not a DSF issue directly.
Source Lookup
Same as with Breakpoints. CDT model Source
Locator and Source Containers can be used by DSF without any changes.
Disassembly
This is where things get a little more
complicated. CDT disassembly API is an extension to the standard debug model,
which is to be implemented by DSF but only as a legacy compatibility
layer. So even if we don't many any changes in CDT by 4.1 (or 5.0), we
should still have a way to use the CDT disassembly view. But ideally we
would like to define a new disassembly API in CDT, which does not depent on
standard debug model objects (IDebugTarget, etc).
Registers
CDT adds methods in the Registers view for defining
custom register groups. I haven't looked closely at the API used by this
feature, but registers configuration is a pretty key area for DD and will
likely require a more sophisticated solution. So if it's inconvenient to
use the existing API, I'm not sure if we'll try to implement this feature.
Modules View
Mikhail ported the Modules view to the flexible hierarchy
viewer so theoretically DSF should be able to populate its contents with a
completely custom API.
Hope this helps,
-Pawel
Doug Schaefer wrote:
Hey
gang,
If you’ve followed my work on the CDT,
I’m taking a shot at improving it’s usability for desktop
development through my new project called Wascana, http://wascana.sourceforge.net,
which was originally called CDT for Windows. As a key part of that I’ve restarted
my work on the integration with the Windows debug engine. To help me learn DSF,
I would like to use it for the Eclipse side.
But I guess before I start, I have a question. Does
DSF and CDI play nicely together in CDT 4.0.x? Wascana will come with both
Windows SDK support and MinGW gdb which uses CDI, at least for now. If there
are issues and they are simple enough to fix, I’d like to do so for CDT
4.0.1.
BTW, my integration uses JSON (www.json.org) to communicate between Java and a
C++ debugger executable that uses IDebugClient and friends. It’s not MI
and I’m free to specify my own protocol giving me flexibility to decide
what goes on the C++ side versus in Eclipse. Should simplify things, in theory J.
Doug
Schaefer, QNX Software Systems
Eclipse CDT Project
Lead, http://cdtdoug.blogspot.com
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev