Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] MinGW gdb

In order for CDI to really be deprecated DSF needs to reach feature parity.
We outlined these issues at our last face-to-face meeting:

But there is still some work left to be done in DSF. We'll be working on
some of these for CDT 7.0 as we need our DSF-EDC based debugger to have the
same features as our current CDI based debugger.

- Ken

> From: ext Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Date: Thu, 4 Feb 2010 18:21:20 +0100
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Subject: RE: [cdt-dev] MinGW gdb
>> -----Original Message-----
>> From: cdt-dev-bounces@xxxxxxxxxxx
>> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
>> Sent: February-04-10 12:03 PM
>> To: CDT General developers list.
>> Subject: Re: [cdt-dev] MinGW gdb
>> On Thu, Feb 4, 2010 at 10:58 AM, Marc Khouzam
>> <marc.khouzam@xxxxxxxxxxxx> wrote:
>>> Sure. However, my plan for the next couple of weeks is to
>>> take another look at our launch story. I hate the fact we
>>> have a default. It should be related to the toolchain that
>>> the user is using for their project. Then when you define
>>> your toolchain, you can say what debugger and integration
>>> framework to use.
>> Are you talking about end-users defining the toolchain or
>> vendors?  If we're talking about end-users, then
>> I think we all agreed it was not a good final solution
>> to make the users _have_ to choose a debugger integration
>> framework.  That is why we have the default.
>> I knew that wording was bad :). I am making the assumption
>> that end users don't define toolchains, only vendors, distro
>> makers,  and ourselves with our exemplary integrations.
> I understand better now :-)
>> But won't the same problem come up when defining a toolchain?
>> Which debugger integration will be the default when you are
>> defining a toolchain?
>> Part of the toolchain definition is the debugger you are
>> using. If you have the same compiler with two debuggers, you
>> have two toolchains.
> Right, but if we take DSF-GDB and CDI-GDB as examples, having
> GDB as the debugger of my toolchain, does not guide me as to which
> integration to use.  We'll still need to have a default selection.
>> I'm thinking we need to have default for the people that fit
>> in the category: "I just want to debug my application".
>> And for those people, I think the default should be
>> the integration that gives them the most debugging features.
>> The CDT is a diverse community, and for the most part, they
>> already have a debugger in mind. Which is why I prefer we
>> don't pick a default, but provide a platform and maybe a
>> collection of tool chain integrations that allow the
>> downstream distributors to provide what best suites their audience.
> That sounds good.
> But when I think the plain user that just wants to debug their app,
> I still get the feeling we should make things as transparent as possible.
>> To be honest, I'm on DSF/GDB's side, and for our exemplary
>> tools, most of them will be hooked up to DSF/GDB. But the Mac
>> is a great example. If CDI/GDB works better there, and GDB
>> 7.0 isn't available there, why would we make DSF/GDB the
>> default there?
> Good point.  However, I've tried hard to get the Mac support for
> DSF-GDB to work as well as CDI.  In fact, we had reached that point
> until last night, when new patches were committed to CDI :-)
> I am all for continuing to make CDI work whenever the community
> contributes patches.  However, I am hoping that efforts put towards
> CDI are not taken away from DSF-GDB, as this is probably not the most
> efficient way to proceed.
> Mac is a good example again in this case, as we got good patches for
> DSF-GDB as soon as we were clear that this was the future for CDT,
> instead of focusing on CDI.
> I'm hoping that we can get some traction through such efforts and that
> more and more DSF-GDB patches will come in to fix whatever issues there
> are that affect a specific platform/community.
> Thanks
> Marc
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top