Multiple breakpoint locations

Multiple breakpoint locations

[Nick Roberts]

The new code for breakpoints with multiple locations looks very good and
addresses a common complaint about GDB.  I have a couple of points and
apologise if they have already been discussed.

Folowing the example in the manual:

     Num     Type           Disp Enb  Address    What
     1       breakpoint     keep y    <MULTIPLE>
             stop only if i==1
             breakpoint already hit 1 time
     1.1                         y    0x080486a2 in void foo<int>() at t.cc:8
     1.2                         y    0x080486ca in void foo<double>() at t.cc:8


1) I can enable/disable 1.1 and 1.2 but not delete them:

  (gdb) dis 1.1

     Num     Type           Disp Enb  Address    What
     1       breakpoint     keep y    <MULTIPLE>
             stop only if i==1
             breakpoint already hit 1 time
     1.1                         n    0x080486a2 in void foo<int>() at t.cc:8
     1.2                         y    0x080486ca in void foo<double>() at t.cc:8

  (gdb) d 1.1
  warning: bad breakpoint number at or near '1.1'

2) I can enable/disable 1 and this appears to enable/disable all the locations.
   Perhap this could be documented in the manual.

3) I created this breakpoint by specifying the line but if I do:

    b foo<int>()

   or any variant I can think of, I just get a pending breakpoint as GDB
   doesn't recognise the location.  Can such locations be specified on the
   command line by name?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Multiple breakpoint locations

[Vladimir Prus]

Nick Roberts wrote:

> 
> The new code for breakpoints with multiple locations looks very good and
> addresses a common complaint about GDB.  I have a couple of points and
> apologise if they have already been discussed.
> 
> Folowing the example in the manual:
> 
>      Num     Type           Disp Enb  Address    What
>      1       breakpoint     keep y    <MULTIPLE>
>              stop only if i==1
>              breakpoint already hit 1 time
>      1.1                         y    0x080486a2 in void foo<int>() at
>      t.cc:8
>      1.2                         y    0x080486ca in void foo<double>() at
>      t.cc:8
> 
> 
> 1) I can enable/disable 1.1 and 1.2 but not delete them:
> 
>   (gdb) dis 1.1
> 
>      Num     Type           Disp Enb  Address    What
>      1       breakpoint     keep y    <MULTIPLE>
>              stop only if i==1
>              breakpoint already hit 1 time
>      1.1                         n    0x080486a2 in void foo<int>() at
>      t.cc:8
>      1.2                         y    0x080486ca in void foo<double>() at
>      t.cc:8
> 
>   (gdb) d 1.1
>   warning: bad breakpoint number at or near '1.1'

Well, you can't really delete a location -- if breakpoint expression
corresponds to 20 addresses, that's the way it is -- you cannot delete
some of those addresses from the program ;-)

> 2) I can enable/disable 1 and this appears to enable/disable all the
> locations.
>    Perhap this could be documented in the manual.

Well yes. Patches welcome ;-)

> 3) I created this breakpoint by specifying the line but if I do:
> 
>     b foo<int>()
> 
>    or any variant I can think of, I just get a pending breakpoint as GDB
>    doesn't recognise the location.  Can such locations be specified on the
>    command line by name?

Does

        b 'void foo<int>()'

work better?

- Volodya

Re: Multiple breakpoint locations

[Daniel Jacobowitz]

On Tue, Nov 13, 2007 at 10:28:15PM +0300, Vladimir Prus wrote:
> > 3) I created this breakpoint by specifying the line but if I do:
> > 
> >     b foo<int>()
> > 
> >    or any variant I can think of, I just get a pending breakpoint as GDB
> >    doesn't recognise the location.  Can such locations be specified on the
> >    command line by name?
> 
> Does
> 
>         b 'void foo<int>()'
> 
> work better?

I have some patches in progress which should make 'break foo<int>'
work.  I posted one of them a month or so ago; I have not committed it
yet, because I was disappointed by the performance cost, but I can't
think of any real alternatives.  So I probably will commit it soon
and then finish the other patches.

I've gotten caught up in another project at the moment, though, so
not right away.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Multiple breakpoint locations

[Nick Roberts]

 > >   (gdb) d 1.1
 > >   warning: bad breakpoint number at or near '1.1'
 > 
 > Well, you can't really delete a location -- if breakpoint expression
 > corresponds to 20 addresses, that's the way it is -- you cannot delete
 > some of those addresses from the program ;-)

It's not immediately obvious, at least to me, so I think this should be
documented.  Also I think error should be used for the message instead of
warning as the requested task is not performed. The message could be more
helpful too:

(gdb) d 1.1
This breakpoint cannot be deleted on its own.

 > > 2) I can enable/disable 1 and this appears to enable/disable all the
 > > locations.
 > >    Perhap this could be documented in the manual.
 > 
 > Well yes. Patches welcome ;-)

I don't want to detract from the fact that you have contributed a major
patch but I think you should document your own changes.  This is also a
good idea because you understand the changes best.

 > > 3) I created this breakpoint by specifying the line but if I do:
 > > 
 > >     b foo<int>()
 > > 
 > >    or any variant I can think of, I just get a pending breakpoint as GDB
 > >    doesn't recognise the location.  Can such locations be specified on the
 > >    command line by name?
 > 
 > Does
 > 
 >         b 'void foo<int>()'
 > 
 > work better?

Yes, thanks.  It seems strange to me that the return type needs to be
specified.  I thought with overloading, people talked about signature which
is determined by the name and arguments but not the return type.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Multiple breakpoint locations

[Daniel Jacobowitz]

On Wed, Nov 14, 2007 at 09:09:05AM +1300, Nick Roberts wrote:
> Yes, thanks.  It seems strange to me that the return type needs to be
> specified.  I thought with overloading, people talked about signature which
> is determined by the name and arguments but not the return type.

It's a quirk of the way C++ gnuv3 mangling works.  I get someone to
explain to me why the return type is included about once a year, and
then promptly forget again.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Multiple breakpoint locations

[Bob Rossi]

On Wed, Nov 14, 2007 at 09:09:05AM +1300, Nick Roberts wrote:
>  > >   (gdb) d 1.1
>  > >   warning: bad breakpoint number at or near '1.1'
>  > 
>  > Well, you can't really delete a location -- if breakpoint expression
>  > corresponds to 20 addresses, that's the way it is -- you cannot delete
>  > some of those addresses from the program ;-)
> 
> It's not immediately obvious, at least to me, so I think this should be
> documented.  Also I think error should be used for the message instead of
> warning as the requested task is not performed. The message could be more
> helpful too:
> 
> (gdb) d 1.1
> This breakpoint cannot be deleted on its own.

Yeah, this is yet another leaky abstraction. The common user has no idea
why multiple breakpoints are created at once, and why they can not
delete only one of the multiple added. 

I like the idea of showing the description. Perhaps with a reason why.

>  > > 2) I can enable/disable 1 and this appears to enable/disable all the
>  > > locations.
>  > >    Perhap this could be documented in the manual.
>  > 
>  > Well yes. Patches welcome ;-)
> 
> I don't want to detract from the fact that you have contributed a major
> patch but I think you should document your own changes.  This is also a
> good idea because you understand the changes best.

Again, this is going to be something that is asked over and over. I
think it'd be great to have it in the manual.

Bob Rossi

Re: Multiple breakpoint locations

[Vladimir Prus]

On Tuesday 13 November 2007 23:09:05 Nick Roberts wrote:
>  > >   (gdb) d 1.1
>  > >   warning: bad breakpoint number at or near '1.1'
>  > 
>  > Well, you can't really delete a location -- if breakpoint expression
>  > corresponds to 20 addresses, that's the way it is -- you cannot delete
>  > some of those addresses from the program ;-)
> 
> It's not immediately obvious, at least to me, so I think this should be
> documented.  Also I think error should be used for the message instead of
> warning as the requested task is not performed. The message could be more
> helpful too:
> 
> (gdb) d 1.1
> This breakpoint cannot be deleted on its own.

Indeed, the error message could be better. Though it would require each
breakpoint-related function to be enhanced to recognize "N.M" and 
say it's not appropriate here.

>  > > 2) I can enable/disable 1 and this appears to enable/disable all the
>  > > locations.
>  > >    Perhap this could be documented in the manual.
>  > 
>  > Well yes. Patches welcome ;-)
> 
> I don't want to detract from the fact that you have contributed a major
> patch but I think you should document your own changes.  This is also a
> good idea because you understand the changes best.

I've documented them, but you're finding the documentation not good ;-) 
Basically, as a practical matter it might take me a long time to get
to any doc edits.

- Volodya 

Re: Multiple breakpoint locations

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

> Yes, thanks.  It seems strange to me that the return type needs to be
> specified.  I thought with overloading, people talked about signature which
> is determined by the name and arguments but not the return type.

For function templates the return type is part of the signature (it can
be parameterised with a template argument).

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: Multiple breakpoint locations

[Vladimir Prus]

Andreas Schwab wrote:

> Nick Roberts <nickrob@snap.net.nz> writes:
> 
>> Yes, thanks.  It seems strange to me that the return type needs to be
>> specified.  I thought with overloading, people talked about signature
>> which is determined by the name and arguments but not the return type.
> 
> For function templates the return type is part of the signature (it can
> be parameterised with a template argument).

I'm not sure it's true. Consider:

        template<class T>
        T foo();

        template<class T>
        void bar();

The value of template parameter is indeed the part of signature.
The return value does not seem to be, since it directly depends
on template parameter, so:

        foo<int>()

quite uniquely specify the type of return value.

- Volodya

Re: Multiple breakpoint locations

[Andreas Schwab]

Vladimir Prus <ghost@cs.msu.su> writes:

> Andreas Schwab wrote:
>
>> Nick Roberts <nickrob@snap.net.nz> writes:
>> 
>>> Yes, thanks.  It seems strange to me that the return type needs to be
>>> specified.  I thought with overloading, people talked about signature
>>> which is determined by the name and arguments but not the return type.
>> 
>> For function templates the return type is part of the signature (it can
>> be parameterised with a template argument).
>
> I'm not sure it's true.

It is valid for function template instantiations to only differ in the
return type.  See <http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg02798.html>
for an example.

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: Multiple breakpoint locations

[Jim Blandy]

Andreas Schwab <schwab at suse.de> writes:
> It is valid for function template instantiations to only differ in the
> return type.  See <http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg02798.html>
> for an example.

Following that link, I think I now better appreciate why full C++
support in GDB is basically impossible: in order to decide which 'fun'
template the call in 'main' refers to, one must try to instantiate
each template and type-check the resulting code.  So GDB would need to
essentially incorporate a full C++ front end.

Re: Multiple breakpoint locations

[Vladimir Prus]

Jim Blandy wrote:

> 
> Andreas Schwab <schwab at suse.de> writes:
>> It is valid for function template instantiations to only differ in the
>> return type.  See <http://gcc.gnu.org/ml/gcc-bugs/2003-06/msg02798.html>
>> for an example.
> 
> Following that link, I think I now better appreciate why full C++
> support in GDB is basically impossible: in order to decide which 'fun'
> template the call in 'main' refers to, one must try to instantiate
> each template and type-check the resulting code.  So GDB would need to
> essentially incorporate a full C++ front end.

Or have GCC export a library that GDB can use -- which seems right
approach.

Generally, overload resolution in C++ involves instantiating templates
and evaluating constant expressions and yes, that requires knowing lots of things.

- Volodya

Re: Multiple breakpoint locations

[Andreas Schwab]

Jim Blandy <jimb@codesourcery.com> writes:

> Following that link, I think I now better appreciate why full C++
> support in GDB is basically impossible: in order to decide which 'fun'
> template the call in 'main' refers to, one must try to instantiate
> each template and type-check the resulting code.  So GDB would need to
> essentially incorporate a full C++ front end.

It's even worse.  You can put the function templates in different source
files so that two function calls using the same parameters instantiate
functions from different templates, all in the same program.

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: Multiple breakpoint locations

[Eli Zaretskii]

> Cc: Vladimir Prus <ghost@cs.msu.su>,  gdb@sources.redhat.com
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Wed, 14 Nov 2007 13:26:26 -0800
> 
> Following that link, I think I now better appreciate why full C++
> support in GDB is basically impossible: in order to decide which 'fun'
> template the call in 'main' refers to, one must try to instantiate
> each template and type-check the resulting code.  So GDB would need to
> essentially incorporate a full C++ front end.

The information emitted by the compiler (which already has a full C++
implementation) could help, couldn't it?

Re: Multiple breakpoint locations

[Daniel Jacobowitz]

On Thu, Nov 15, 2007 at 06:08:08AM +0200, Eli Zaretskii wrote:
> > Cc: Vladimir Prus <ghost@cs.msu.su>,  gdb@sources.redhat.com
> > From: Jim Blandy <jimb@codesourcery.com>
> > Date: Wed, 14 Nov 2007 13:26:26 -0800
> > 
> > Following that link, I think I now better appreciate why full C++
> > support in GDB is basically impossible: in order to decide which 'fun'
> > template the call in 'main' refers to, one must try to instantiate
> > each template and type-check the resulting code.  So GDB would need to
> > essentially incorporate a full C++ front end.
> 
> The information emitted by the compiler (which already has a full C++
> implementation) could help, couldn't it?

It helps, but not much more than we use it already.  The debug info
isn't designed to include some of the extra details needed to figure
out where things are visible and what all the options are.

In my opinion, we do this well enough.  Every once in a while I poke
at doing overloading and template selection better in GDB, but what
we have is adequate for most uses and the marginal work required to
improve it is substantial.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Multiple breakpoint locations

[Jim Blandy]

Eli Zaretskii <eliz at gnu.org> writes:

>> Cc: Vladimir Prus <ghost@cs.msu.su>,  gdb@sources.redhat.com
>> From: Jim Blandy <jimb@codesourcery.com>
>> Date: Wed, 14 Nov 2007 13:26:26 -0800
>> 
>> Following that link, I think I now better appreciate why full C++
>> support in GDB is basically impossible: in order to decide which 'fun'
>> template the call in 'main' refers to, one must try to instantiate
>> each template and type-check the resulting code.  So GDB would need to
>> essentially incorporate a full C++ front end.
>
> The information emitted by the compiler (which already has a full C++
> implementation) could help, couldn't it?

Actually, it doesn't.  Did you follow the link Andreas posted?

When the user enters a source expression referring to some function,
and we have several function templates in scope under the given name,
the process of deciding which function template's instantiation the
user's expression actually refers to involves essentially trying out
each template, typechecking its entire body, and rejecting the
template if a problem arises.

The debugging information could carry the templates' definitions to
us, giving us enough information to do the work --- but the work
itself is not much less complicated than a C++ front end.

In practice, the debugging information does not carry the definitions
of all the templates in scope, because it would often be huge.  You
will often have many templates in scope that you never used --- from
header files, say.  In order to carry out the process described above,
the debugging information would need to carry the templates' complete
definitions, including statements and expressions, not just summary
information like what a C declaration carries.  And those full
definitions can be substantial.

Restricting yourself to templates actually instantiated in the program
would bring the size issue under control, but it doesn't address the
'complete C++ front end' issue.

Re: Multiple breakpoint locations

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Tue, 13 Nov 2007 22:28:15 +0300
> 
> >   (gdb) d 1.1
> >   warning: bad breakpoint number at or near '1.1'
> 
> Well, you can't really delete a location -- if breakpoint expression
> corresponds to 20 addresses, that's the way it is -- you cannot delete
> some of those addresses from the program ;-)

Sorry, I don't understand why; can you please elaborate?  Removing a
breakpoint instruction from a specific address is a primitive
operation of the target back-end; why can't we use it for that single
address?

Re: Multiple breakpoint locations

[Douglas Evans]

On Nov 13, 2007 2:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > From:  Vladimir Prus <ghost@cs.msu.su>
> > Date:  Tue, 13 Nov 2007 22:28:15 +0300
> >
> > >   (gdb) d 1.1
> > >   warning: bad breakpoint number at or near '1.1'
> >
> > Well, you can't really delete a location -- if breakpoint expression
> > corresponds to 20 addresses, that's the way it is -- you cannot delete
> > some of those addresses from the program ;-)
>
> Sorry, I don't understand why; can you please elaborate?  Removing a
> breakpoint instruction from a specific address is a primitive
> operation of the target back-end; why can't we use it for that single
> address?

I think it's a question of how much complexity one wants here.  AIUI,
the breakpoint is represented as source+line.  One would have to
augment that to mean source+line+except-this (I think).

Also, it's not just "delete 1.1".  It's also condition, commands, and
ignore.  I'm not suggesting all (or any) should be supported, just
that we shouldn't tackle any of them without thinking the big picture
through at least a bit.  As of today, in the context of `delete,
condition, commands, ignore' there is just one breakpoint with N
sub-breakpoints (so to speak).  [AIUI of course.]

Re: Multiple breakpoint locations

[Eli Zaretskii]

> Date: Tue, 13 Nov 2007 15:39:31 -0800
> From: "Douglas Evans" <dje@google.com>
> Cc: "Vladimir Prus" <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> On Nov 13, 2007 2:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> > > From:  Vladimir Prus <ghost@cs.msu.su>
> > > Date:  Tue, 13 Nov 2007 22:28:15 +0300
> > >
> > > >   (gdb) d 1.1
> > > >   warning: bad breakpoint number at or near '1.1'
> > >
> > > Well, you can't really delete a location -- if breakpoint expression
> > > corresponds to 20 addresses, that's the way it is -- you cannot delete
> > > some of those addresses from the program ;-)
> >
> > Sorry, I don't understand why; can you please elaborate?  Removing a
> > breakpoint instruction from a specific address is a primitive
> > operation of the target back-end; why can't we use it for that single
> > address?
> 
> I think it's a question of how much complexity one wants here.  AIUI,
> the breakpoint is represented as source+line.  One would have to
> augment that to mean source+line+except-this (I think).

Not necessarily.  You could look up the struct bp_location that
corresponds to 1.1 (by using its address as a key), and remove that
struct bp_location from the chain we maintain for breakpoint 1.

> Also, it's not just "delete 1.1".  It's also condition, commands, and
> ignore.

Well, removing struct bp_location should take care of that as well.
Am I missing something?

> I'm not suggesting all (or any) should be supported, just that we
> shouldn't tackle any of them without thinking the big picture
> through at least a bit.

Well, my big picture is that today we have no solution for the
following use case: (a) I set a breakpoint that results in multiple
locations; (b) I look at "info break" and realize that some of these
locations are irrelevant for the problem I'm debugging, and I don't
want the program to stop there (e.g., maybe stopping there will
disrupt some timing); (c) I want to remove these locations from the
breakpoints list.

Re: Multiple breakpoint locations

[Joel Brobecker]

> > I think it's a question of how much complexity one wants here.  AIUI,
> > the breakpoint is represented as source+line.  One would have to
> > augment that to mean source+line+except-this (I think).
> 
> Not necessarily.  You could look up the struct bp_location that
> corresponds to 1.1 (by using its address as a key), and remove that
> struct bp_location from the chain we maintain for breakpoint 1.

The design issue occurs in certain situations when we have to
recompute the breakpoint location addresses. For instance, when
a shared library gets loaded, we recompute the breakpoint locations.
So, when you delete a bp_location, we need to have a way of being
able to make sure that it is not re-inserted the next time we
recompute the breakpoint locations.

We could compromise and have a caveat where GDB doesn't worry for now
about remembering which bp_location we deleted. This might cause a
bp_location to re-appear unexpectedly, but there will be some situations
under which things should work fine. For instance, if the breakpoint
is inserted after the program has been started and all shared libraries
are loaded, as long as the program does not load manually extra shared
libraries, it shouldn't be a problem. It's a bit dogdy, and will require
ample documentation, but it's a thought.

-- 
Joel

Re: Multiple breakpoint locations

[Vladimir Prus]

Eli Zaretskii wrote:

>> Date: Tue, 13 Nov 2007 15:39:31 -0800
>> From: "Douglas Evans" <dje@google.com>
>> Cc: "Vladimir Prus" <ghost@cs.msu.su>, gdb@sources.redhat.com
>> 
>> On Nov 13, 2007 2:18 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > > From:  Vladimir Prus <ghost@cs.msu.su>
>> > > Date:  Tue, 13 Nov 2007 22:28:15 +0300
>> > >
>> > > >   (gdb) d 1.1
>> > > >   warning: bad breakpoint number at or near '1.1'
>> > >
>> > > Well, you can't really delete a location -- if breakpoint expression
>> > > corresponds to 20 addresses, that's the way it is -- you cannot
>> > > delete some of those addresses from the program ;-)
>> >
>> > Sorry, I don't understand why; can you please elaborate?  Removing a
>> > breakpoint instruction from a specific address is a primitive
>> > operation of the target back-end; why can't we use it for that single
>> > address?

Because after that, the output of 'info break' will no longer correspond
accurately to what the program is. If there are 20 locations in program,
and 'info break' shows 20 locations, it means the user sees *all* locations.
He can disable some of them, and then he'll see that some of locations
are disabled. If you allow removing a location, it means the list of location
starts to show all locations except for previously removed ones, and there's
no way to investigate which removed locations were there, how many are
removed and so on. It seems to be that disabling undesired locations
is more transparent approach.

>> I think it's a question of how much complexity one wants here.  AIUI,
>> the breakpoint is represented as source+line.  One would have to
>> augment that to mean source+line+except-this (I think).
> 
> Not necessarily.  You could look up the struct bp_location that
> corresponds to 1.1 (by using its address as a key), and remove that
> struct bp_location from the chain we maintain for breakpoint 1.
> 
>> Also, it's not just "delete 1.1".  It's also condition, commands, and
>> ignore.
> 
> Well, removing struct bp_location should take care of that as well.
> Am I missing something?
> 
>> I'm not suggesting all (or any) should be supported, just that we
>> shouldn't tackle any of them without thinking the big picture
>> through at least a bit.
> 
> Well, my big picture is that today we have no solution for the
> following use case: (a) I set a breakpoint that results in multiple
> locations; (b) I look at "info break" and realize that some of these
> locations are irrelevant for the problem I'm debugging, and I don't
> want the program to stop there (e.g., maybe stopping there will
> disrupt some timing); (c) I want to remove these locations from the
> breakpoints list.

You disable those locations, and gdb no longer stops there. And GDB, furthermore,
will try hard to keep those locations disabled as shared libraries are 
loaded and unloaded.

- Volodya

Re: Multiple breakpoint locations

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Wed, 14 Nov 2007 09:13:16 +0300
> 
> >> > Sorry, I don't understand why; can you please elaborate?  Removing a
> >> > breakpoint instruction from a specific address is a primitive
> >> > operation of the target back-end; why can't we use it for that single
> >> > address?
> 
> Because after that, the output of 'info break' will no longer correspond
> accurately to what the program is.

I need it to correspond to the way I want the program to be stopped,
not to all possible ways a source-level locations specification can be
interpreted in terms of an address.  The latter is of course a correct
starting point, but if I then chose that some of the addresses don't
make sense for me, there's no reason I should see them just for
completeness' sake.

> > Well, my big picture is that today we have no solution for the
> > following use case: (a) I set a breakpoint that results in multiple
> > locations; (b) I look at "info break" and realize that some of these
> > locations are irrelevant for the problem I'm debugging, and I don't
> > want the program to stop there (e.g., maybe stopping there will
> > disrupt some timing); (c) I want to remove these locations from the
> > breakpoints list.
> 
> You disable those locations, and gdb no longer stops there.

That's just a workaround.  The same logic could be used to argue that
there's no need to have the "delete" command at all: you can always
disable the critter.

Re: Multiple breakpoint locations

[Vladimir Prus]

Eli Zaretskii wrote:

>> From:  Vladimir Prus <ghost@cs.msu.su>
>> Date:  Wed, 14 Nov 2007 09:13:16 +0300
>> 
>> >> > Sorry, I don't understand why; can you please elaborate?  Removing a
>> >> > breakpoint instruction from a specific address is a primitive
>> >> > operation of the target back-end; why can't we use it for that
>> >> > single address?
>> 
>> Because after that, the output of 'info break' will no longer correspond
>> accurately to what the program is.
> 
> I need it to correspond to the way I want the program to be stopped,
> not to all possible ways a source-level locations specification can be
> interpreted in terms of an address.  The latter is of course a correct
> starting point, but if I then chose that some of the addresses don't
> make sense for me, there's no reason I should see them just for
> completeness' sake.
> 
>> > Well, my big picture is that today we have no solution for the
>> > following use case: (a) I set a breakpoint that results in multiple
>> > locations; (b) I look at "info break" and realize that some of these
>> > locations are irrelevant for the problem I'm debugging, and I don't
>> > want the program to stop there (e.g., maybe stopping there will
>> > disrupt some timing); (c) I want to remove these locations from the
>> > breakpoints list.
>> 
>> You disable those locations, and gdb no longer stops there.
> 
> That's just a workaround.  The same logic could be used to argue that
> there's no need to have the "delete" command at all: you can always
> disable the critter.

I disagree. breakpoint is something you create yourself, and it's
natural you can delete something you've created. Locations exist
in the program independent of you, and it's natural to be able
to disable some locations. And, BTW, once you've deleted a breakpoint,
you can create it afresh because you presumably remember how it was
created. If you delete a location, how you recover it back? By
deleting the breakpoint, creating it again, and losing enable/disable
state on other unrelated locations?

- Volodya

Re: Multiple breakpoint locations

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 14 Nov 2007 08:15:27 +1300
> 
> 
> The new code for breakpoints with multiple locations looks very good and
> addresses a common complaint about GDB.  I have a couple of points and
> apologise if they have already been discussed.

Thanks for your suggestions, I fixed the manual as shown below:

2007-11-17  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Set Breaks, Disabling): Clarify behavior of
	breakpoints with multiple locations.
	(Breakpoint Menus): Improve wording.


Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.444
diff -u -r1.444 gdb.texinfo
--- gdb/doc/gdb.texinfo	15 Nov 2007 18:43:23 -0000	1.444
+++ gdb/doc/gdb.texinfo	17 Nov 2007 11:48:53 -0000
@@ -2992,7 +2992,7 @@
 @item Enabled or Disabled
 Enabled breakpoints are marked with @samp{y}.  @samp{n} marks breakpoints
 that are not enabled.  An optional @samp{(p)} suffix marks pending
-breakpoints --- breakpoints for which address is either not yet
+breakpoints---breakpoints for which address is either not yet
 resolved, pending load of a shared library, or for which address was
 in a shared library that was since unloaded.  Such breakpoint won't
 fire until a shared library that has the symbol or line referred by
@@ -3001,7 +3001,7 @@
 Where the breakpoint is in your program, as a memory address.  For a
 pending breakpoint whose address is not yet known,  this field will
 contain @samp{<PENDING>}.  A breakpoint with several locations will
-have @samp{<MULTIPLE>} in this field --- see below for details.
+have @samp{<MULTIPLE>} in this field---see below for details.
 @item What
 Where the breakpoint is in the source for your program, as a file and
 line number.  For a pending breakpoint, the original string passed to
@@ -3060,16 +3060,16 @@
 In all those cases, @value{GDBN} will insert a breakpoint at all
 the relevant locations.
 
-A breakpoint with multiple locations is displayed in the
-breakpoint table using several rows --- one header row, followed
-by one row for each breakpoint location.  The header row
-has @samp{<MULTIPLE>} in the address column.  The rows for
-individual locations contain the actual addresses for locations,
-and say what functions those locations are in.  The number
-column for a location has number in the format
+A breakpoint with multiple locations is displayed in the breakpoint
+table using several rows---one header row, followed by one row for
+each breakpoint location.  The header row has @samp{<MULTIPLE>} in the
+address column.  The rows for individual locations contain the actual
+addresses for locations, and show the functions to which those
+locations belong.  The number column for a location is of the form
 @var{breakpoint-number}.@var{location-number}.
 
 For example:
+
 @smallexample
 Num     Type           Disp Enb  Address    What
 1       breakpoint     keep y    <MULTIPLE>
@@ -3081,11 +3081,17 @@
 
 Each location can be individually enabled or disabled by passing
 @var{breakpoint-number}.@var{location-number} as argument to the
-@code{enable} and @code{disable} commands.
+@code{enable} and @code{disable} commands.  Note that you cannot
+delete the individual locations from the list, you can only delete the
+entire list of locations that be long to their parent breakpoint (with
+the @kbd{delete @var{num}} command, where @var{num} is the number of
+the parent breakpoint, 1 in the above example).  Disabling or enabling
+the parent breakpoint (@pxref{Disabling}) affects all of the locations
+that belong to that breakpoint.
 
 @cindex pending breakpoints
 It's quite common to have a breakpoint inside a shared library.
-The shared library may be loaded and unloaded explicitly,
+Shared libraries can be loaded and unloaded explicitly,
 and possibly repeatedly, as the program is executed.  To support
 this use case, @value{GDBN} updates breakpoint locations whenever
 any shared library is loaded or unloaded.  Typically, you would
@@ -3093,7 +3099,7 @@
 debugging session, when the library is not loaded, and when the
 symbols from the library are not available.  When you try to set
 breakpoint, @value{GDBN} will ask you if you want to set
-a so called @dfn{pending breakpoint} --- breakpoint whose address
+a so called @dfn{pending breakpoint}---breakpoint whose address
 is not yet resolved.
 
 After the program is run, whenever a new shared library is loaded,
@@ -3544,6 +3550,9 @@
 @code{info watch} to print a list of breakpoints, watchpoints, and
 catchpoints if you do not know which numbers to use.
 
+Disabling and enabling a breakpoint that has multiple locations
+affects all of its locations.
+
 A breakpoint, watchpoint, or catchpoint can have any of four different
 states of enablement:
 
@@ -3808,8 +3817,8 @@
 to be defined several times, for application in different contexts.
 This is called @dfn{overloading}.  When a function name is overloaded,
 @samp{break @var{function}} is not enough to tell @value{GDBN} where you want
-a breakpoint.  If you realize this is a problem, you can use
-something like @samp{break @var{function}(@var{types})} to specify which
+a breakpoint.  You can use explicit signature of the function, as in
+@samp{break @var{function}(@var{types})}, to specify which
 particular version of the function you want.  Otherwise, @value{GDBN} offers
 you a menu of numbered choices for different possible breakpoints, and
 waits for your selection with the prompt @samp{>}.  The first two

Re: Multiple breakpoint locations

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 14 Nov 2007 08:15:27 +1300
> 
> 
> The new code for breakpoints with multiple locations looks very good and
> addresses a common complaint about GDB.  I have a couple of points and
> apologise if they have already been discussed.

Btw, while working on Nick's proposals, I found myself confused wrt
the connection, if any, between the feature described in "Breakpoint
Menus" and the multiple-location breakpoints that was the subject of
this thread.

Are these features the same (i.e., is the format of the
multiple-locations breakpoint listing described in "Set Break" what we
use for breakpoints set from the menu described in "Breakpoint
Menus")?  Or are they two different features?

If the former, won't additional locations, which we didn't select from
the menu, appear in the list of locations as result of loading shared
libraries that define additional overloaded variants of the function
in which we wanted to break?

If the latter, I cannot seem to find the description of how multiple
locations come into existence in the first place anywhere in the
manual.  Am I missing something?

Re: Multiple breakpoint locations

[Vladimir Prus]

Eli Zaretskii wrote:

>> From: Nick Roberts <nickrob@snap.net.nz>
>> Date: Wed, 14 Nov 2007 08:15:27 +1300
>> 
>> 
>> The new code for breakpoints with multiple locations looks very good and
>> addresses a common complaint about GDB.  I have a couple of points and
>> apologise if they have already been discussed.
> 
> Btw, while working on Nick's proposals, I found myself confused wrt
> the connection, if any, between the feature described in "Breakpoint
> Menus" and the multiple-location breakpoints that was the subject of
> this thread.
> 
> Are these features the same (i.e., is the format of the
> multiple-locations breakpoint listing described in "Set Break" what we
> use for breakpoints set from the menu described in "Breakpoint
> Menus")?  Or are they two different features?

They are different. "Breakpoint menus" are for overloaded function, where
a single name 'foo' may refer to completely different functions in source
code. Multiple locations handle a case where a specific function in source
corresponds to multiple PC values. 

> 
> If the former, won't additional locations, which we didn't select from
> the menu, appear in the list of locations as result of loading shared
> libraries that define additional overloaded variants of the function
> in which we wanted to break?
> 
> If the latter, I cannot seem to find the description of how multiple
> locations come into existence in the first place anywhere in the
> manual.  Am I missing something?

The manual lists cases where a given function in source can correspond to
several PC values, and they say:

        In all those cases, @value{GDBN} will insert a breakpoint at all
        the relevant locations.

So it happens automatically.

- Volodya

Re: Multiple breakpoint locations

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Sat, 17 Nov 2007 17:13:18 +0300
> 
> > If the latter, I cannot seem to find the description of how multiple
> > locations come into existence in the first place anywhere in the
> > manual.  Am I missing something?
> 
> The manual lists cases where a given function in source can correspond to
> several PC values, and they say:
> 
>         In all those cases, @value{GDBN} will insert a breakpoint at all
>         the relevant locations.
> 
> So it happens automatically.

Well, I think it's not explicit enough.  I will try to add some more
explicit explanations when I have time.

Re: Multiple breakpoint locations

[Nick Roberts]

 > > The manual lists cases where a given function in source can correspond to
 > > several PC values, and they say:
 > > 
 > >         In all those cases, @value{GDBN} will insert a breakpoint at all
 > >         the relevant locations.
 > > 
 > > So it happens automatically.
 > 
 > Well, I think it's not explicit enough.  I will try to add some more
 > explicit explanations when I have time.

The only way I've managed to create breakpoints at multiple locations is
by specifying a line number inside the template/constructor.  For templates
I understand that the breakpoints are for different types, e.g., float, int
as used by the program.  For constructors:


   * For a C++ constructor, the GCC compiler generates several
     instances of the function body, used in different cases.

I don't understand what the second breakpoint refers to, or why there may
be more than one instance.

So I think, at some point, a separate node, or one grouped with breakpoint
menus to highlight the differences, would be a good idea.  Other things, like
needing to include the return type in the template name when specifying a
breakpoint location could also be included.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Multiple breakpoint locations

[Daniel Jacobowitz]

On Sun, Nov 18, 2007 at 02:32:42PM +1300, Nick Roberts wrote:
>    * For a C++ constructor, the GCC compiler generates several
>      instances of the function body, used in different cases.
> 
> I don't understand what the second breakpoint refers to, or why there may
> be more than one instance.

GCC generates two copies of the constructor.  One is used to construct
whole objects; the other is used to construct not-in-charge virtual
base classes.  You can find out more about this at
http://www.codesourcery.com/cxx-abi/ and in the C++ language standard,
if you're interested.

> So I think, at some point, a separate node, or one grouped with breakpoint
> menus to highlight the differences, would be a good idea.  Other things, like
> needing to include the return type in the template name when specifying a
> breakpoint location could also be included.

If I can find the time, I hope to get this fixed before the end of the
year.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Multiple breakpoint locations

[Nick Roberts]

 > > So I think, at some point, a separate node, or one grouped with breakpoint
 > > menus to highlight the differences, would be a good idea.  Other things,
 > > like needing to include the return type in the template name when
 > > specifying a breakpoint location could also be included.
 > 
 > If I can find the time, I hope to get this fixed before the end of the
 > year.

But Andreas has said that:

"For function templates the return type is part of the signature"

and

"It is valid for function template instantiations to only differ in the
return type."

which suggests to me that the return type is a necessary part of the name.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Multiple breakpoint locations

[Daniel Jacobowitz]

On Sun, Nov 18, 2007 at 09:46:53PM +1300, Nick Roberts wrote:
> But Andreas has said that:
> 
> "For function templates the return type is part of the signature"
> 
> and
> 
> "It is valid for function template instantiations to only differ in the
> return type."
> 
> which suggests to me that the return type is a necessary part of the name.

True, but in most cases it is not necessary to disambiguate.  Only in
the rare cases where the program contains two instantiations which
differ only in return type.

-- 
Daniel Jacobowitz
CodeSourcery