Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz <drow@false.org>]

On Sat, Jan 14, 2006 at 05:15:07AM -0500, Paul Hilfinger wrote:
> 
> > We have discussed this issue many times in the past, as recently as two
> > weeks ago.  In the beginning of 2005 I posted a prototype patch to set
> > only a single breakpoint, but associate it with multiple locations.  I
> > still firmly believe that that is the correct solution.  However, the
> > patch was never finished.
> 
> [The patch Daniel refers to here, by the way, is 
> 
>    http://sources.redhat.com/ml/gdb-patches/2005-03/msg00195.html]
> 
> What led you to conclude that you wouldn't need the ability to set (or
> delete) only SOME breakpoints corresponding to a given location (i.e.,
> some number greater than, say, 2 and less than all)?  I can see one possible
> reason: since the 'command' and 'condition' commands do not take 
> BP ranges, it is difficult to apply them to lots of breakpoints.  On the
> other hand, one could extend these commands to allow a range of breakpoints
> rather than a single breakpoint.  But then on the third hand (first foot?),
> the implementation would require some annoying manipulations to avoid
> double freeing (of expressions or command sequences) or other atrocities.

Just to be clear, there's no "range of breakpoints" concept in my
solution.  You get a single breakpoint, say, breakpoint number 2, which
corresponds to twenty occurances of some inlined function.

I have no objection to commands for finer grained modification of
breakpoints.  But they're going to be tricky to get right, because in
this new system I want to always keep some hard problems in mind.  For
example, preserving the enable state of breakpoints sensibly over a
recompiled and reloaded application.  If you've got "break foo.c:20"
and suddenly there's a new instance of it and it maps to 21 breakpoints
instead of 20, that's good.  If you've somehow said "disable 2 location
4" to disable just one of those twenty breakpoints, and now there are
21 instead of 20, you need to figure out which one's been disabled
by the user!

> > Those menus have got to go.  They're (a) confusing to users (in my
> > opinion, no real data), and (b) extremely awkward for graphical
> > frontends.
> 
> Interesting.  As I said, in Ada, the multi-line feature is much more
> important than in C.  AdaCore's version has been around for years, and
> has simply created multiple breakpoints (controlled by menu, as for
> overloading).  We haven't gotten loud calls for doing things
> differently (well, point (b) has caused internal gripes), but perhaps I
> should do some polling for soft grumbling from users.

From what I've seen, in GNAT (a) is less likely to be true.  In any
system where the compiler is likely to produce copies of a function
without clear explanation to the user, it's much more confusing.  GCC
will surely do this soon, e.g. for interprocedural constant
propagation.

-- 
Daniel Jacobowitz
CodeSourcery