| RE: [dsdp-dd-dev] Windows Debugger |
|
Thanks, Pawel, I just checked out the DSF
plug-ins and will start looking at the current gdb launch configuration. I’ll
probably do my own launch config, something like “Windows C++ Application”.
My first step will be to be able to debug an application with no breakpoints,
just to get the launching side of things working and to start populating the
Debug view. The next step is stopping at the breakpoint at main and then go
from there. As I come up with questions, I’ll
fire them here. It’ll be a fairly slow process since I’m doing a
lot of other things at the same time. Cheers,
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On
Behalf Of Pawel Piech Hi Doug, 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.
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.
_______________________________________________dsdp-dd-dev mailing listdsdp-dd-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
|