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
|