Re: [F114-003] - ACT #999: Discuss possible changes to handling of multiple breakpoints

[Robert A Duff <duff at gnat dot com>]

I hope I'm sending this to the right places...

Cyrille Comar wrote:

> Ok, here is some soft grumblings from a long-standing internal user of
> the AdaCore version: grumble grumble...
> ;-)

I agree that those menus are annoying.  Particularly in scripts.  I think
Cyrille is on the right track, here (see below), despite various objections
I've read in followups.

A few points:

I don't use the debugger very much.  So I want it to "do the right thing"
without too much knowledge on my part.  (As opposed to the language, where
I'm willing to learn every little detail, and the compiler, where I'm
willing to read docs about all kinds of switches and whatnot.)

Inlining is different from generic instantiation.

If I break on a line in a procedure that is inlined, I almost certainly want
to break in all copies of that code.  I don't care about individual call
sites.  (And if I do care about individual call sites, I would care just as
much for out-of-line calls.  That is, a feature "break here when called from
there" might be useful, but its usefulness is independent of whether the
thing is inlined.)

Generic instantiation (or templates in C++) is different.  There, the
separate copies of code are semantically significant, and understood by the
programmer.  (Still, I _usually_ want to break on all instances, not just
one -- if there's a bug in an instance procedure, it probably exists in
_all_ instances.)

If I ask to break on a function in a generic, and it says there are 37 cases
(because there are 37 instantiations), I usually say "all".  Then I'm happy
if I can disable the ones I don't care about, one by one, as they occur.
If any.

Gdb's overload resolution rules are not quite the same as Ada's,
so it sometimes reports a conflict when there is none.  This is
technically a bug, I think, but it's probably too hard to fix in
general.  (Sigh.)

> I agree with Daniel's (a) & (b). I have never grumbled before on this
> topic because I did not have anything constructive to contribute. This
> thread gave me an idea. Here it is:
> 
> I believe it would be worthwhile to have 2 different break commands:
>       - break
>       - break-multiple (or whatever other more appropriate name)
> 
> break-multiple would have the semantics advocated by Daniel (break
> automatically on all relevant locations)
> 
> break, instead of presenting a menu, would issue an error of the kind:
> 
> (gdb) break FILENAME:LINENUM
> multiple choices for this breakpoint, please use any of the following:
> break-multiple FILENAME:LINENUM
> break FILENAME:instance1.function:LINENUM
> break FILENAME:instance2.function:LINENUM
> break FILENAME:instance3.function:LINENUM
> 
> 
> That solves 4 issues:
>     - an experienced user can do exactly what she wants
>     - a less experienced user can copy/paste the appropriate choice from
> the error message
>     - there is no more awkward interactive menu in text mode
>     - a graphical interface can easily parse the error output and do
> whatever deemed appropriate in the interface (presenting a menu for
> instance)

Maybe the details above are wrong.  But I think the general idea is
good.  I would rather learn some incantation to make it do what I want,
rather than being continually pestered by those interactive menus.

- Bob