[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-debug-dev] GDB support in CDT
|
The gdb support IS in the separate plugins: org.eclipse.cdt.debug.mi.core and
org.eclipse.cdt.debug.mi.ui. There are many companies that ship their
products based on
this implementation. I believe they will find resources to support
the existing code.
The problem currently as I see it is that the GDB plugin is tied to
the CDT development project schedule. GDB support could do with much
more rapid cycles(stable releases 1/year'ish + snapshots for the brave
monthly or so). Hence my desire for splitting GDB support from CDT. In
fact, I'd like to see the GDB plugin 100% independent of CDT
altogether(I'm not sure that there exists concepts in Eclipse for
supporting side-by-side installs of two plugins using different
underlying CDT versions).
Does GDB have to be tied to CDT development cycles?
I'm getting mixed messages from the CDT team on whether any further
development will take place on the GDB plugin. Feel free to clarify
what the consensus is on this one.
By the way, switching to the new debug model (what you call the
WindRiver stuff) is not
going to solve the current problems with the gdb implementation. It
is restiricted by the
(in)abilities of gdb itself, not the model.
I'm not all hot and bothered about the WinDriver stuff. I just want
bugfixes to the existing stuff. It actually works pretty well.
And by the way, there have been serious changes and additions in the
3.1 release - the
support of custom command factories, more flexible launcher classes
to create custom
launch configurations, not to mention your favorite verbose console mode.
Yup. Thanks!
--
Øyvind Harboe
http://www.zylin.com
