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?

[Vladimir Prus]

Post by 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.
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
(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 ;-)

Post by Nick Roberts
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 ;-)

Post by Nick Roberts
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

[Daniel Jacobowitz]

Post by Vladimir Prus

Post by Nick Roberts
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.

[Nick Roberts]

Post by Vladimir Prus

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

Post by Vladimir Prus

Post by Nick Roberts
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.

Post by Vladimir Prus

Post by Nick Roberts
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.

[Daniel Jacobowitz]

Post by Nick Roberts
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.

[Bob Rossi]

Post by Nick Roberts

Post by Vladimir Prus

Post by 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
(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.

Post by Nick Roberts

Post by Vladimir Prus

Post by Nick Roberts
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

[Vladimir Prus]

Post by Nick Roberts

Post by Vladimir Prus

Post by 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
(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.

Post by Nick Roberts

Post by Vladimir Prus

Post by Nick Roberts
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

[Andreas Schwab]

Post by Nick Roberts
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.

[Vladimir Prus]

Post by Andreas Schwab

Post by Nick Roberts
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

[Andreas Schwab]

Post by Vladimir Prus

Post by Andreas Schwab

Post by Nick Roberts
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.

[Jim Blandy]

Post by Andreas Schwab
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.

[Vladimir Prus]

Post by Jim Blandy

Post by Andreas Schwab
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

[Andreas Schwab]

Post by Jim Blandy
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.

[Eli Zaretskii]

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?

[Daniel Jacobowitz]

Post by Eli Zaretskii

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.

[Jim Blandy]

Post by Eli Zaretskii

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.

[Eli Zaretskii]

Date: Tue, 13 Nov 2007 22:28:15 +0300

Post by 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 ;-)

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?

[Douglas Evans]

Post by Eli Zaretskii

Date: Tue, 13 Nov 2007 22:28:15 +0300

Post by 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 ;-)

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

[Eli Zaretskii]

Date: Tue, 13 Nov 2007 15:39:31 -0800

Post by Eli Zaretskii

Date: Tue, 13 Nov 2007 22:28:15 +0300

Post by 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 ;-)

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.

[Joel Brobecker]

Post by Eli Zaretskii

Post by Douglas Evans
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.

[Vladimir Prus]

Post by Eli Zaretskii

Date: Tue, 13 Nov 2007 15:39:31 -0800

Post by Eli Zaretskii

Date: Tue, 13 Nov 2007 22:28:15 +0300

Post by 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 ;-)

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.

Post by Eli Zaretskii

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

[Eli Zaretskii]

Date: Wed, 14 Nov 2007 09:13:16 +0300

Post by Eli Zaretskii

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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.

[Vladimir Prus]

Post by Eli Zaretskii

Date: Wed, 14 Nov 2007 09:13:16 +0300

Post by Eli Zaretskii

Post by Eli Zaretskii
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.

Post by Eli Zaretskii
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

[Eli Zaretskii]

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 <***@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

[Eli Zaretskii]

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?

[Vladimir Prus]

Post by Eli Zaretskii

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.

Post by Eli Zaretskii
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

[Eli Zaretskii]

Date: Sat, 17 Nov 2007 17:13:18 +0300

Post by Eli Zaretskii
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
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.

[Nick Roberts]

Post by Eli Zaretskii

Post by Vladimir Prus
The manual lists cases where a given function in source can correspond to
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.

[Daniel Jacobowitz]

Post by Nick Roberts
* 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.

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

[Nick Roberts]

Post by Daniel Jacobowitz

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

[Daniel Jacobowitz]

Post by Nick Roberts
"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.