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