Re: [RFC] multiple breakpoints from FILE:LINE

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

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

[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

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

[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

[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

[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

[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

[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

[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

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

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

[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