RE: [cdt-dev] MinGW gdb

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ken.ryall@xxxxxxxxx
> Sent: February-04-10 12:30 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: 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:
> 
> http://wiki.eclipse.org/CDT/summitfall2008/Debug_Session
> 
> 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.

That is very good news.  Thanks Ken.

Another way I was hoping to get some efforts put it towards those
issues was a bit of a "sink or swim" approach.  The community
is not helping us fix those issues because they are not seeing
those issues.  Making DSF-GDB the default over CDI-GDB would
make those issue more visible; it would hurt a bit at first,
but I believe things would get fixed once they're visible.

That makes me think that we should make a decision as soon as
possible; that way, when people install preliminary CDT 7.0 builds
they'd get the new debugger default and report problems right
away, while we still have time to work on them for Helios.
If we get some really bad 'reviews' we'd still have time to change
our minds.

What do you think?

Marc





> - 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
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>