[RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

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