[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] [DSF-GDB] Pending breakpoint support

We can't do that because we still have to support customers using gdb
6.7 or even 5.2.

What I am thinking is to create my own "gdbDebugServiceFactory" and
different CommandFactories. I may have to override the "MIBreakInsert"
too.

As of the Break Point markers, the changes in MIBreakpointsManager are
in private methods so I don't think I can override without copying the
whole class but then I have to deal with all references to it...


-----Original Message-----
From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
Reply-to: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
To: 'elaskavaia.cdt@xxxxxxxxx' <elaskavaia.cdt@xxxxxxxxx>, 'CDT General
developers list.' <cdt-dev@xxxxxxxxxxx>
Subject: RE: [cdt-dev] [DSF-GDB] Pending breakpoint support
Date: Tue, 24 Aug 2010 14:57:04 -0400

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
> Sent: Tuesday, August 24, 2010 2:39 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] [DSF-GDB] Pending breakpoint support
> 
> Ok. So conclusion is:
> 1) We will attach 7.0 patch but we won't apply it. Users or orgs who
> want it can apply themselves.
> 2) We (at qnx) will probably check out 7.0.1, patch it and build
> locally, unless we can find a solution to override some command
> factories using existing API's.

If you don't care about GDB versions before 6.8, you can make the fix
more simple, by blindly adding the -f option to MIBreakInsert.java
You still need the changes for the bp markers though

> 
> On Tue, Aug 24, 2010 at 2:25 PM, Marc Khouzam 
> <marc.khouzam@xxxxxxxxxxxx> wrote:
> >
> > As a note, we can re-work the patch to have only backwards
> > compatible changes, if that were the only issue.
> >
> > The change remains significant though, as we would set
> > every single breakpoint using a extra GDB option.  This
> > is what has always made me uncomfortable about this solution
> > going in late in a release.
> >
> > Marc
> >
> >
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> >> Sent: Tuesday, August 24, 2010 1:01 PM
> >> To: CDT General developers list.
> >> Subject: Re: [cdt-dev] [DSF-GDB] Pending breakpoint support
> >>
> >> It is a new feature. And I am disappointed it took so long 
> for people
> >> to notice it missing. But we are where we are.
> >>
> >> I'd say forking is your best option. API changes will break
> >> the 7.0.1 build.
> >>
> >> And again, this is the main use case driving our move to git. You
> >> should be able to clone the main repo and create your 
> branch locally
> >> and continue to merge in fixes from the community as you 
> go. You may
> >> be able to use the cvs git mirrors to do that for now, in theory.
> >>
> >> On Tue, Aug 24, 2010 at 12:46 PM, Andy Jin <ajin@xxxxxxx> wrote:
> >> > Hi, John,
> >> >
> >> > Do we have any other option besides forking the branch? And
> >> do you agree
> >> > that this is a bug instead of a new feature - as 
> indicated by Elena?
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: John Cortell <rat042@xxxxxxxxxxxxx>
> >> > Reply-to: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> >> > To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>, 
> CDT General
> >> > developers list. <cdt-dev@xxxxxxxxxxx>
> >> > Subject: RE: [cdt-dev] [DSF-GDB] Pending breakpoint support
> >> > Date: Tue, 24 Aug 2010 11:31:03 -0500
> >> >
> >> > My two cents. No matter how important a feature it is,
> >> introducing it
> >> > in a point release is unwise. Stability is of utmost 
> importance in a
> >> > point release. Breakpoints are a notoriously
> >> difficult/complex aspect
> >> > of a debugger. I personally don't think we should make 
> an exception.
> >> >
> >> > John
> >> >
> >> > At 10:40 AM 8/24/2010, Andy Jin wrote:
> >> >>I verified the patch works. I think the remaining U.I. 
> issues do not
> >> >>prevent us from applying this patch.
> >> >>
> >> >>The question now is - can we have the similar fix to the
> >> cdt_7_0 branch?
> >> >>
> >> >>The problem is that (as mentioned in the bug) this is 
> considered new
> >> >>feature so IMHO our options are:
> >> >>
> >> >>1) Apply the patch to the cdt_7_0 branch and treat it as
> >> one exception.
> >> >>This is tough but does anyone think this feature is
> >> important enough to
> >> >>be treated as one exception? Do we have enough community
> >> votes to bring
> >> >>this up?
> >> >>
> >> >>2) Ask whoever integrates from the cdt_7_0 branch to fork
> >> the branch and
> >> >>fix it in his/her own copy.
> >> >>
> >> >>Is there any other option?
> >> >>
> >> >>Thanks,
> >> >>Andy
> >> >>
> >> >>-----Original Message-----
> >> >>From: Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
> >> >>Reply-to: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> >> >>To: CDT General developers list. <cdt-dev@xxxxxxxxxxx>
> >> >>Subject: RE: [cdt-dev] [DSF-GDB] Pending breakpoint support
> >> >>Date: Sat, 21 Aug 2010 23:17:17 -0400
> >> >>
> >> >>I have posted a partial fix to the bug
> >> >>https://bugs.eclipse.org/bugs/show_bug.cgi?id=248595
> >> >>
> >> >>With that partial fix, when using GDB >=6.8, DSF-GDB will set
> >> >>pending breakpoints properly.
> >> >>
> >> >>I say the fix is 'partial' because any breakpoint that does not
> >> >>install right away (pending) will never
> >> >>be marked as installed, even if it actually interrupts the
> >> >>execution.  The solution to this was discussed in the
> >> >>bug, but requires more time, which I don't personally have.  If
> >> >>anyone wants to take care of
> >> >>that, I'll review it.
> >> >>
> >> >>Note also that with this solution, there would no longer be a
> >> >>warning marker when a breakpoint
> >> >>does not install properly.  That means that breakpoints 
> of another
> >> >>eclipse project will no
> >> >>longer show a warning, but simply won't show as installed.
> >> We could choose to
> >> >>still show a warning, maybe with explanatory text, but I
> >> wasn't sure what was
> >> >>more user-friendly.
> >> >>
> >> >>I think this solution, although partial, is an improvement on the
> >> >>current situation, and therefore worth
> >> >>committing.  But I'll wait to see if anyone disagrees.
> >> >>
> >> >>Marc
> >> >>
> >> >>________________________________________
> >> >>From: cdt-dev-bounces@xxxxxxxxxxx 
> [cdt-dev-bounces@xxxxxxxxxxx] On
> >> >>Behalf Of Doug Schaefer [cdtdoug@xxxxxxxxx]
> >> >>Sent: August 20, 2010 2:25 PM
> >> >>To: CDT General developers list.
> >> >>Subject: Re: [cdt-dev] [DSF-GDB] Pending breakpoint support
> >> >>
> >> >>+1. This is definitely not minor, at least for the community.
> >> >>
> >> >>On Fri, Aug 20, 2010 at 2:20 PM, Andy Jin <ajin@xxxxxxx> wrote:
> >> >> > Just wondering what's the plan for pending breakpoint 
> support in
> >> >> > DSF-GDB?
> >> >> >
> >> >> > I see it is still listed as one missing feature parity
> >> with CDI but it's
> >> >> > listed under the "minor" section
> >> >> > (http://wiki.eclipse.org/CDT/cdt-debug-feature-parity-effort).
> >> >> >
> >> >> > Without this feature we can't debug share library which
> >> is not loaded at
> >> >> > program startup; and this (supposed) is a pretty common
> >> requirement.
> >> >> >
> >> >> > >From this point on this bug should not be considered 
> minor, am I
> >> >> > correct?
> >> >> >
> >> >> > Thanks,
> >> >> > Andy
> >> >> > _______________________________________________
> >> >> > 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____________
> >> ___________________________________
> >> >>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
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >> >
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> 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