: Re: [RFC] multiple breakpoints from FILE:LINE

: Re: [RFC] multiple breakpoints from FILE:LINE

[Cyrille Comar]

 >> 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.

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

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)

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Paul Koning]

>>>>> "Cyrille" == Cyrille Comar <comar@adacore.com> writes:

 >>> 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....

 Cyrille> I agree with Daniel's (a) & (b). I have never grumbled
 Cyrille> before on this topic because I did not have anything
 Cyrille> constructive to contribute. This thread gave me an
 Cyrille> idea. Here it is:

 Cyrille> I believe it would be worthwhile to have 2 different break
 Cyrille> commands: - break - break-multiple (or whatever other more
 Cyrille> appropriate name)

 Cyrille> break-multiple would have the semantics advocated by Daniel
 Cyrille> (break automatically on all relevant locations)

 Cyrille> break, instead of presenting a menu, would issue an error of
 Cyrille> the kind:

 Cyrille> (gdb) break FILENAME:LINENUM multiple choices for this
 Cyrille> breakpoint, please use any of the following: break-multiple
 Cyrille> FILENAME:LINENUM break FILENAME:instance1.function:LINENUM

Nice.  What syntax would you use for the two constructors, and three
destructors, that have the same C++ names?

	     paul

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

On Sun, Jan 15, 2006 at 11:33:11AM -0500, Paul Koning wrote:
>  Cyrille> I believe it would be worthwhile to have 2 different break
>  Cyrille> commands: - break - break-multiple (or whatever other more
>  Cyrille> appropriate name)
> 
>  Cyrille> break-multiple would have the semantics advocated by Daniel
>  Cyrille> (break automatically on all relevant locations)
> 
>  Cyrille> break, instead of presenting a menu, would issue an error of
>  Cyrille> the kind:
> 
>  Cyrille> (gdb) break FILENAME:LINENUM multiple choices for this
>  Cyrille> breakpoint, please use any of the following: break-multiple
>  Cyrille> FILENAME:LINENUM break FILENAME:instance1.function:LINENUM

Well, I think this should be just one command, and maybe have "break"
in the CLI issue a warning (just like it does now).  But that's a
relatively small change.

The instance1.function syntax handles one important Ada case, but
there's plenty of other cases; for instance, there can be an arbitrary
chain of inlining.  I'm not convinced that there's any practical way to
get it right.

> Nice.  What syntax would you use for the two constructors, and three
> destructors, that have the same C++ names?

I've yet to see a compelling reason to break on one constructor and not
the other.  Most users don't even know the difference between when each
is called.

-- 
Daniel Jacobowitz
CodeSourcery

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

>
> >>> 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....
>
> Cyrille> I agree with Daniel's (a) & (b). I have never grumbled
> Cyrille> before on this topic because I did not have anything
> Cyrille> constructive to contribute. This thread gave me an
> Cyrille> idea. Here it is:
>  
>
I strongly object to removing the menus which are very convenient to
use. No proposal here comes close to being as convenient. For the
overriding case, here is typical usage:

(gdb) pn (parent (1666))
Multiple matches for parent
[0] cancel
[1] atree.parent at /M/gnat5/src/gcc/ada/atree.adb:2104
[2] nlists.parent at /M/gnat5/src/gcc/ada/nlists.adb:1020
 > 1
N_Assignment_Statement (Node_Id=1665) (source)
 Sloc = 9928  a.adb:4:6
 Name = N_Identifier "x" (Node_Id=1662)
 Expression = N_Op_Divide "Odivide" (Node_Id=1666)

Certainly you want the menu in that case I would
assume (I can't see an alternative).

So if I do

(gdb) break parent
[0] cancel
[1] all
[2] atree.parent at /M/gnat5/src/gcc/ada/atree.adb:2104
[3] nlists.parent at /M/gnat5/src/gcc/ada/nlists.adb:1020
 > 2
Breakpoint 6 at 0x43e755: file c:/M/gnat5/src/gcc/ada/atree.adb, line 2104.

again, typing 2/return is very simple, I certainly don't want to have to go
looking up where parent is declared and typing its line number in the
first place, and copying and pasting a command is far slower than typing
2/return.

In the GUI case I have to click on an alternative either way, so what's

Note that indeed it is the case that it is important (crucial I
would say) to be able to place a breakpoint on only one occurrence.


the difference?

> Cyrille> I believe it would be worthwhile to have 2 different break
> Cyrille> commands: - break - break-multiple (or whatever other more
> Cyrille> appropriate name)
>
> Cyrille> break-multiple would have the semantics advocated by Daniel
> Cyrille> (break automatically on all relevant locations)
>
> Cyrille> break, instead of presenting a menu, would issue an error of
> Cyrille> the kind:
>
> Cyrille> (gdb) break FILENAME:LINENUM multiple choices for this
> Cyrille> breakpoint, please use any of the following: break-multiple
> Cyrille> FILENAME:LINENUM break FILENAME:instance1.function:LINENUM
>
>Nice.  What syntax would you use for the two constructors, and three
>destructors, that have the same C++ names?
>
>  
>
Does not look nice at all to me, it is far more work to cut and paste a 
break
command than to type one digit.

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

Daniel Jacobowitz wrote:

>I've yet to see a compelling reason to break on one constructor and not
>the other.  Most users don't even know the difference between when each
>is called.
>  
>
On the other hand, with overloaded procedures, it is normal
to want to break on only one. For instance, when debugging
gnat, there are lots of cases of a C routine in the back end
and an Ada routine in the front end having the same name,
and you definitely want to be able to break on one without
breaking on the other. The current menu method in the
Ada version of GDB is convenient for this and I don't
see any alternative that is as convenient, let alone more
convenient.

Re: [RFC] multiple breakpoints from FILE:LINE

[Paul Hilfinger]

Cyrille Comar writes:

> 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)

But then 'break', being the shorter and more familiar command name,
would appear from a user's point of view to be the effective default.
If you put a breakpoint in the middle of an inline function (or an Ada
generic procedure or C++ template class method), it seems rather odd
for the default to be "break on one at random" [well, OK; that's what
it is in regular GDB now, but currently there is no alternative, so
there is no choice about defaults].  So if you went the distinct-
command route, you'd probably want 'break' and 'break-single' (er, or
something), the latter being a seldom-chosen specialized command that
would present a menu.  Another alternative is a new settable variable.

Paul Hilfinger

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Paul Koning]

Daniel Jacobowitz wrote:
>I've yet to see a compelling reason to break on one constructor and not
>the other.  Most users don't even know the difference between when each
>is called.

I suspect that's because the whole thing is undocumented, or close
enough as to make no difference.

I'm not sure if it has come up in my work, but it doesn't seem out of
the question to want to break on a constructor/destructor of a class
when that class is the top level class (i.e., [in-charge]
constructor).  

	       paul

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Jim Blandy]

On 1/15/06, Robert Dewar <dewar@adacore.com> wrote:
> I strongly object to removing the menus which are very convenient to
> use. No proposal here comes close to being as convenient. For the
> overriding case, here is typical usage:

Your example doesn't correspond to the case we're discussing.

In your example (if I'm guessing my way through Ada and your .gdbinit
user-defined functions properly), there is an ambiguity in what
"parent" refers to; the menu lets you select one.

But the case being discussed in this thread is menus that appear in
response to a location specified by a filename and line number.  It's
not clear that the kind of legitimate ambiguity you're concerned about
is present here.

When a function has been inlined, it's odd for users to demand to be
able to set breakpoints on one inlined instance but not another.  You
can't set a breakpoint on a function conditional on it having been
called from a certain place; why would users suddenly require that
functionality just because the compiler decided to optimize the code
in a certain way?

In-charge and not-in-charge constructors are a similar situation. 
There's nothing in the semantics of the source language that ever
suggests that there are two separate reifications of the single block
of code the user wrote.  This differs from instantiations of generics,
which (if I understand right) are things that the user actually did
ask for.  The two constructor instances don't behave differently, as
far as the source level in concerned.  Separating the two is purely an
implementation strategy, and should be hidden from the user when
reasonable.

In cases where the same code has been #included twice, I think there's
more of a case that users might want to choose one or the other, since
it is indeed explicit in the source code that this particular source
line is going to contribute twice to the translation unit.  But even
here, setting the breakpoint in both places would be a clear
improvement over what we do now: choose one #inclusion randomly.

(The last time we discussed this, Michael Chastain pointed out that
you actually *do* want to choose a specific constructor instance when
you're disassembling.  But we're talking about breakpoints here; the
decision just needs to be made at the right place, so we can do one
thing for 'break' and a different thing for 'disass'.)

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

Jim Blandy wrote:

>But the case being discussed in this thread is menus that appear in
>response to a location specified by a filename and line number.  It's
>not clear that the kind of legitimate ambiguity you're concerned about
>is present here.
>  
>
OK, understood.

>When a function has been inlined, it's odd for users to demand to be
>able to set breakpoints on one inlined instance but not another.  You
>can't set a breakpoint on a function conditional on it having been
>called from a certain place; why would users suddenly require that
>functionality just because the compiler decided to optimize the code
>in a certain way?
>  
>
I agree with this for the caser of inlined procedures, and I don't think 
it is
even necessary to have the possibility of setting breakpoints on an instance
by instance basis

>In-charge and not-in-charge constructors are a similar situation. 
>There's nothing in the semantics of the source language that ever
>suggests that there are two separate reifications of the single block
>of code the user wrote.  This differs from instantiations of generics,
>which (if I understand right) are things that the user actually did
>ask for.  The two constructor instances don't behave differently, as
>far as the source level in concerned.  Separating the two is purely an
>implementation strategy, and should be hidden from the user when
>reasonable.
>  
>
I agree

>In cases where the same code has been #included twice, I think there's
>more of a case that users might want to choose one or the other, since
>it is indeed explicit in the source code that this particular source
>line is going to contribute twice to the translation unit.  But even
>here, setting the breakpoint in both places would be a clear
>improvement over what we do now: choose one #inclusion randomly.
>  
>
Indeed, one random instance is for suer wrong

>(The last time we discussed this, Michael Chastain pointed out that
>you actually *do* want to choose a specific constructor instance when
>you're disassembling.  But we're talking about breakpoints here; the
>decision just needs to be made at the right place, so we can do one
>thing for 'break' and a different thing for 'disass'.)
>  
>
There is one more case, related to the #include case, which is generic 
templates in Ada, and here
too I think you want the possibility of setting a breakpoint in specific 
instances.

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

Jim Blandy wrote:

>In your example (if I'm guessing my way through Ada and your .gdbinit
>user-defined functions properly), there is an ambiguity in what
>"parent" refers to; the menu lets you select one.
>  
>
Just to be clear here. Cyrille Comar had said that he does not
want the menus in the "legitimate ambiguity" (overloading)
case either, and that's what I was disagreeing with.

I agree that the file:line situation is quite different, and I think
the idea of two possible commands there makes sense (though
I still question the need in the inlined subprogram case).

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Cyrille Comar]

Daniel Jacobowitz wrote:
> I've yet to see a compelling reason to break on one constructor and not
> the other.  Most users don't even know the difference between when each
> is called.

I am not familiar at all with C++ debugging, so the situation is not 
clear to me: To break on constructors, do you use the FILE:LINE of the 
class? Wouldn't that break on destructors as well? (or any other type 
specific implicit operation, if such thing exists in C++)

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

On Mon, Jan 16, 2006 at 02:34:15PM +0100, Cyrille Comar wrote:
> Daniel Jacobowitz wrote:
> >I've yet to see a compelling reason to break on one constructor and not
> >the other.  Most users don't even know the difference between when each
> >is called.
> 
> I am not familiar at all with C++ debugging, so the situation is not 
> clear to me: To break on constructors, do you use the FILE:LINE of the 
> class? Wouldn't that break on destructors as well? (or any other type 
> specific implicit operation, if such thing exists in C++)

No, you either use Class::Class or Class::~Class, or the FILE:LINE of a
user-provided definition.  They all have names whether or not they have
explicit definitions.

-- 
Daniel Jacobowitz
CodeSourcery

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Cyrille Comar]

Daniel Jacobowitz wrote:

> No, you either use Class::Class or Class::~Class, 

ok so this is not strictly the topic as decribed in the subject line. 
Does it make more sense to widen the topic to include overloading and 
implicit operations and more generally any multiple-breakpoints-at-once 
issues or is it better to stick to the cases covered by the subject 
line? That would cover inlining, C++ templates, Ada generics, C include 
  files.

It seems that each situation is relatively specific. At least, there 
seem to be 2 different categories:

    - inlining & constructors : where it has been advocated that a 
single   break command should insert multiple breakpoints

    - overloading, generics, templates, includes: where it has been 
advocated that some kind of choice is needed.

Re: : Re: [RFC] multiple breakpoints from FILE:LINE

[Paul Koning]

Daniel Jacobowitz wrote:
> I've yet to see a compelling reason to break on one constructor and not
> the other.  Most users don't even know the difference between when each
> is called.

I am not familiar at all with C++ debugging, so the situation is not 
clear to me: To break on constructors, do you use the FILE:LINE of the 
class? Wouldn't that break on destructors as well? (or any other type 
specific implicit operation, if such thing exists in C++)

I'm assuming the case where a programmer wrote an explicit
constructor.  In that case, you can break on it either by name
("Class::Class") or by line number (pointing at the constructor
function body).

	 paul