: 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]

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

[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

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

[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: [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: [RFC] multiple breakpoints from FILE:LINE

[David Anderson]

The  multiple breakpoints due-to-inlining discussion has
mentioned 20 or 21 breakpoints.

What if there are 200 or  2000 or 20000 or more inlining sites
of one function?

A breakpoint listing won't be very usable either, whether of
2000 entries or one entry with 2000 break addresses. Will it?

[Sorry, no proposal here. Just raising the issue.]
David Anderson

Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

On Sun, Jan 15, 2006 at 09:36:51AM -0800, David Anderson wrote:
> The  multiple breakpoints due-to-inlining discussion has
> mentioned 20 or 21 breakpoints.
> 
> What if there are 200 or  2000 or 20000 or more inlining sites
> of one function?
> 
> A breakpoint listing won't be very usable either, whether of
> 2000 entries or one entry with 2000 break addresses. Will it?

That's why I was not planning on showing the list of locations by
default - you'd have to "drill down" into it for details.  Yes, I've
thought about this issue.

It will require changes in lots of other bits of GDB, though.  For
instance removing and reinserting all breakpoints becomes impractical.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

David Anderson wrote:

>The  multiple breakpoints due-to-inlining discussion has
>mentioned 20 or 21 breakpoints.
>
>What if there are 200 or  2000 or 20000 or more inlining sites
>of one function?
>  
>
For me, the case of inlining is very different from the case of an
Ada instantiation or from overloading. I find it hard to imagine
wanting to breakpoint one particular inline instance. In fact it
really seems conceptually wrong, whether a function is inlined
or not is an implementation detail that should not affect debugging
at all.

>A breakpoint listing won't be very usable either, whether of
>2000 entries or one entry with 2000 break addresses. Will it?
>
>[Sorry, no proposal here. Just raising the issue.]
>David Anderson
>  
>

Re: [RFC] multiple breakpoints from FILE:LINE

[Andreas Schwab]

Robert Dewar <dewar@adacore.com> writes:

> For me, the case of inlining is very different from the case of an
> Ada instantiation or from overloading. I find it hard to imagine
> wanting to breakpoint one particular inline instance.

What if you want to debug a particular function which inlines another
function that is also inlined in many other, frequently called functions?
In this case being able to set a breakpoint in a single instance of the
inline function can considerably reduce the complexity of debugging.  Of
course, you can always fall back to setting the breakpoint on an address,
but that makes it difficult to reliably track the breakpoint position when
reloading the binary.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [RFC] multiple breakpoints from FILE:LINE

[Robert Dewar]

Andreas Schwab wrote:

>
>What if you want to debug a particular function which inlines another
>function that is also inlined in many other, frequently called functions?
>In this case being able to set a breakpoint in a single instance of the
>inline function can considerably reduce the complexity of debugging.  Of
>course, you can always fall back to setting the breakpoint on an address,
>but that makes it difficult to reliably track the breakpoint position when
>reloading the binary.
>  
>
Well you would not have this possibility if the function were not inlined,
so I just don't see it as critical functionality.

It's like wanting to breakpoint in one iteration of a loop to me ...
and then you say, "gosh, we are unfolding this loop, so indeed
we could do that and now have to work out a syntax to do it"

>Andreas.
>
>  
>

[RFC] multiple breakpoints from FILE:LINE

[Paul Hilfinger]

In response to

   break FUNCTION

in C++, GDB currently presents one with a list of choices when FUNCTION
is overloaded.  However, this is not the only case in which the target 
of a 'break' command is ambiguous.  Consider

   break FILENAME:LINENUM

Normally, this refers to a single location in a program, but if this line
is in the middle of a C++ template, a multiply #included file, or an
Ada generic definition, it may refer to several locations.  Currently,
GDB chooses one of these silently.

In Ada mode, AdaCore's GNAT Pro version of GDB will also present a menu in 
response to this latter case.  In addition, we introduced a syntax 
(little used, I believe) for specifying a line in one specific generic 
instance:

	break FILENAME:FUNCTION:LINENUM

where FUNCTION here would be fully qualified.   That is, if P1 and P2
are two different instantiations of a generic class defining F, then

    break something.adb:P2.F:12

sets a breakpoint at line 12 in P2.F.

We would like to contribute some version of both of these to the public
sources.  Before doing so, however, we'd like to solicit comments.

Paul Hilfinger

Re: [RFC] multiple breakpoints from FILE:LINE

[Eli Zaretskii]

> From: Paul Hilfinger <hilfingr@gnat.com>
> Date: Fri, 13 Jan 2006 05:42:12 -0500 (EST)
> 
>    break FILENAME:LINENUM
> 
> Normally, this refers to a single location in a program, but if this line
> is in the middle of a C++ template, a multiply #included file, or an
> Ada generic definition, it may refer to several locations.  Currently,
> GDB chooses one of these silently.

Shouldn't it set breakpoints on ALL of those places instead?

> In Ada mode, AdaCore's GNAT Pro version of GDB will also present a menu in 
> response to this latter case.  In addition, we introduced a syntax 
> (little used, I believe) for specifying a line in one specific generic 
> instance:
> 
> 	break FILENAME:FUNCTION:LINENUM
> 
> where FUNCTION here would be fully qualified.   That is, if P1 and P2
> are two different instantiations of a generic class defining F, then
> 
>     break something.adb:P2.F:12
> 
> sets a breakpoint at line 12 in P2.F.

I'm not sure I understand: why isn't something.adb:12 enough to
specify the breakpoint location unambiguously?

Re: [RFC] multiple breakpoints from FILE:LINE

[Joel Brobecker]

> > Normally, this refers to a single location in a program, but if this line
> > is in the middle of a C++ template, a multiply #included file, or an
> > Ada generic definition, it may refer to several locations.  Currently,
> > GDB chooses one of these silently.
> 
> Shouldn't it set breakpoints on ALL of those places instead?

I think so. Either this, or ask the user to choose. I think the current
situation is partly historical: In C, the situations where this happens
are rare...

> I'm not sure I understand: why isn't something.adb:12 enough to
> specify the breakpoint location unambiguously?

This is because you may have several instances of the same line. Imagine
that you have an inlined function defined at foobar.c:12. The function
body is duplicated at each call of the function. If the user asks to
insert a breakpoint at this line, which instance/address should the
debugger use?

-- 
Joel

Re: [RFC] multiple breakpoints from FILE:LINE

[Eli Zaretskii]

> Date: Fri, 13 Jan 2006 15:56:47 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Paul Hilfinger <hilfingr@gnat.com>, gdb@sourceware.org
> 
> > I'm not sure I understand: why isn't something.adb:12 enough to
> > specify the breakpoint location unambiguously?
> 
> This is because you may have several instances of the same line. Imagine
> that you have an inlined function defined at foobar.c:12. The function
> body is duplicated at each call of the function. If the user asks to
> insert a breakpoint at this line, which instance/address should the
> debugger use?

How about something like

    break something.adb:12 if SOME_CONDITION

where SOME_CONDITION is something we should invent to specify the
instance where we want to put the single breakpoint?  This has the
advantage of using an existing syntax, especially if the condition
could be made to use some convenience variable.  By contrast, what you
suggest modifies the syntax of a location specification; do we really
want that?

Re: [RFC] multiple breakpoints from FILE:LINE

[Andrew STUBBS]

Eli Zaretskii wrote:
> How about something like
> 
>     break something.adb:12 if SOME_CONDITION
> 
> where SOME_CONDITION is something we should invent to specify the
> instance where we want to put the single breakpoint?  This has the
> advantage of using an existing syntax, especially if the condition
> could be made to use some convenience variable.  By contrast, what you
> suggest modifies the syntax of a location specification; do we really
> want that?

Not that it makes any real difference but ...

To me that looks like it will set a break point everywhere and then 
check at runtime if it is the right one.

Now I know you weren't thinking of doing that, but that's what the 
condition normally means.

It may also make setting a real condition more tricky.

Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

On Fri, Jan 13, 2006 at 02:15:11PM +0000, Andrew STUBBS wrote:
> Eli Zaretskii wrote:
> >How about something like
> >
> >    break something.adb:12 if SOME_CONDITION
> >
> >where SOME_CONDITION is something we should invent to specify the
> >instance where we want to put the single breakpoint?  This has the
> >advantage of using an existing syntax, especially if the condition
> >could be made to use some convenience variable.  By contrast, what you
> >suggest modifies the syntax of a location specification; do we really
> >want that?
> 
> Not that it makes any real difference but ...
> 
> To me that looks like it will set a break point everywhere and then 
> check at runtime if it is the right one.
> 
> Now I know you weren't thinking of doing that, but that's what the 
> condition normally means.
> 
> It may also make setting a real condition more tricky.

Yes, I agree.

I think we do want to modify the syntax of a location expression,
which is currently somewhat complicated and weakly defined.  However,
I've suggested that we do that as a second step - to specify one single
breakpoint, instead of the multiple ones we'd set by default.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

On Fri, Jan 13, 2006 at 01:32:22PM +0200, Eli Zaretskii wrote:
> > In Ada mode, AdaCore's GNAT Pro version of GDB will also present a menu in 
> > response to this latter case.  In addition, we introduced a syntax 
> > (little used, I believe) for specifying a line in one specific generic 
> > instance:
> > 
> > 	break FILENAME:FUNCTION:LINENUM
> > 
> > where FUNCTION here would be fully qualified.   That is, if P1 and P2
> > are two different instantiations of a generic class defining F, then
> > 
> >     break something.adb:P2.F:12
> > 
> > sets a breakpoint at line 12 in P2.F.
> 
> I'm not sure I understand: why isn't something.adb:12 enough to
> specify the breakpoint location unambiguously?

Think of this as inlining or C++ template instantiation.  P1.F and P2.F
both live at the same location in the source file, which will just
define F (give or take a little - I am not familiar with the details of
Ada generics, but that's the idea).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] multiple breakpoints from FILE:LINE

[Paul Koning]

>>>>> "Paul" == Paul Hilfinger <hilfingr@gnat.com> writes:

 Paul> In response to

 Paul> break FUNCTION

 Paul> in C++, GDB currently presents one with a list of choices when
 Paul> FUNCTION is overloaded.  However, this is not the only case in
 Paul> which the target of a 'break' command is ambiguous.  Consider

 Paul> break FILENAME:LINENUM

 Paul> Normally, this refers to a single location in a program, but if
 Paul> this line is in the middle of a C++ template, a multiply
 Paul> #included file, or an Ada generic definition, it may refer to
 Paul> several locations.  Currently, GDB chooses one of these
 Paul> silently.

Constructors and destructors are another example of this, which is a
known probme of long standing.

 Paul> In Ada mode, AdaCore's GNAT Pro version of GDB will also
 Paul> present a menu in response to this latter case.  In addition,
 Paul> we introduced a syntax (little used, I believe) for specifying
 Paul> a line in one specific generic instance:

 Paul> break FILENAME:FUNCTION:LINENUM

 Paul> where FUNCTION here would be fully qualified.  That is, if P1
 Paul> and P2 are two different instantiations of a generic class
 Paul> defining F, then

 Paul> break something.adb:P2.F:12

 Paul> sets a breakpoint at line 12 in P2.F.

 Paul> We would like to contribute some version of both of these to
 Paul> the public sources.  Before doing so, however, we'd like to
 Paul> solicit comments.

What you describe won't help for constructors or destructors, unless
"fully qualified" means adding some ad-hoc keyword like "[in-charge]"
(as "verbose demangling" does with constructors/destructors).  That's
actually useable, and I have done that in the past as a hacky
workaround for the constructor problem, but I'm not sure if it is the
way to go for a "clean" solution.

    paul

Re: [RFC] multiple breakpoints from FILE:LINE

[Daniel Jacobowitz]

I'll read the rest of the replies momentarily but...

On Fri, Jan 13, 2006 at 05:42:12AM -0500, Paul Hilfinger wrote:
> 
> In response to
> 
>    break FUNCTION
> 
> in C++, GDB currently presents one with a list of choices when FUNCTION
> is overloaded.  However, this is not the only case in which the target 
> of a 'break' command is ambiguous.  Consider
> 
>    break FILENAME:LINENUM
> 
> Normally, this refers to a single location in a program, but if this line
> is in the middle of a C++ template, a multiply #included file, or an
> Ada generic definition, it may refer to several locations.  Currently,
> GDB chooses one of these silently.

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.

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] multiple breakpoints from FILE:LINE

[Joel Brobecker]

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

I'm just worried about the case where you want to break on one
particular instance. It's been a while since I debugged Ada, but
it's not so uncommon. At my previous job, we were still using
Ada83, and some of the limitations of that old revision of the
language led us to use generics in place of function pointers.
We had lots and lots and lots of generics, in particular the
one generic package that we used to implement callbacks. It would
be very difficult to debug this code if we were forced to break
on all of them....

I agree on your (a) and (b), though, expecially (b). As for (a),
it's a slightly complex concept, so I don't know how much we can
do to unconfuse the users...

-- 
Joel

Re: [RFC] multiple breakpoints from FILE:LINE

[Paul Hilfinger]

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

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

Paul Hilfinger

Re: [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