Re: [cdt-dev] Proposed change to behavior of "Show Breakpoints Supported

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx] 
> Sent: Thursday, September 13, 2012 6:44 AM
> To: Marc Khouzam
> Cc: 'CDT General developers list.'
> Subject: Re: [cdt-dev] Proposed change to behavior of "Show 
> Breakpoints Supported by Selected Target"
> 
> On 13.09.2012 14:40, Marc Khouzam wrote:
> >
> >> -----Original Message-----
> >> From: Vladimir Prus [mailto:vladimir@xxxxxxxxxxxxxxxx]
> >> Sent: Thursday, September 13, 2012 3:41 AM
> >> To: CDT General developers list.
> >> Cc: Marc Khouzam
> >> Subject: Re: [cdt-dev] Proposed change to behavior of "Show
> >> Breakpoints Supported by Selected Target"
> >>
> >> On 12.09.2012 23:51, Marc Khouzam wrote:
> >>> Hi,
> >>>
> >>> we would like to propose a change to the behavior of the
> >> button "Show Breakpoints Supported by Selected Target"
> >>> of the Breakpoints view.  This button is provided by the
> >> debug platform, but CDT gives it its functionality
> >>> for C/C++ Debug sessions.  Details and discussion are in
> >> https://bugs.eclipse.org/360735.
> >>>
> >>>
> >>>
> >>>
> >>> Currently, when pressing this button the breakpoints view
> >> will only show breakpoints that are of the same type
> >>> as the debug session.  For example, if debugging Java, only
> >> Java breakpoints will be shown, and if debugging
> >>> C/C++ only C/C++ breakpoints will be shown.
> >>>
> >>> We want to make this behavior more selective and only show
> >> breakpoints that are actually applicable
> >>> to the current debug session.  If you are debugging one
> >> C/C++ application, you would no longer be bothered
> >>> with the breakpoints set in the code of an another C/C++
> >> application.
> >>>
> >>> We propose to make this new behavior the default for CDT,
> >> but to have a new preference to allow users
> >>> or vendors to select the old behavior.
> >>>
> >>> Does anyone have comments or objections?
> >>
> >> So what are we going to do with pending breakpoints, under
> >> this proposal?
> >
> > Good question :)
> > Every breakpoint that does not install on target is marked
> > as pending since GDB cannot know if that piece of code will
> > be loaded in the future or not.  Therefore we must filter out
> > pending breakpoints or else there'd be nothing to filter.
> > However, if a pending breakpoint does get eventually installed,
> > it will no longer be filtered out.  We will be fixing
> > Bug 324300 "Markers are not updated for pending breakpoints
> > that become active"
> > to make this work properly.
> 
> I wonder whether we can remember which breakpoints were ever 
> successfully resolved in
> specific launch configuration and then not filter them out.

I personally like those 'smart' features, but they are sometimes
tricky.  It could be a nice enhancement to the proposal if it
is possible to do right.
 
> I mean, if I have 10 breakpoints in shared libraries, I 
> probably want to be able
> to edit them *before* those shared libraries are loaded.

Absolutely.  You can simply toggle the 
"Show Breakpoints Supported by Selected Target"
to see all breakpoints in that case, edit what you need
and then toggle it again.

Marc