This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [0/9] Breakpoints at multiple locations
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 08 Sep 2007 14:57:46 +0300
- Subject: Re: [0/9] Breakpoints at multiple locations
- References: <200709080011.13700.vladimir@codesourcery.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sat, 8 Sep 2007 00:11:13 +0400
>
> At the moment, gdb assumes that a code breakpoint has
> a single PC value. One case where it does not work
> is C++ constructors -- GCC generates several function
> bodies, and GDB sets breakpoint on just one of them,
> so breakpoints in constructors don't work reliably.
> Another case is C++ templates -- if I set a breakpoint
> on a line in template function, there's unbounded number
> of template instantiations that have this line, but GDB
> cannot set breakpoints on all of them.
>
> I'm about to post a set of patches that fix it. Essentially,
> the patches make breakpoint have a list of breakpoint locations.
> When a breakpoint is creates, GDB automatically figures out the
> set of locations to use. User can than disable locations that seem
> uninteresting to him.
Thanks, this is a great feature to have in GDB.
I hope there will be a suitable patch for the user manual, before all
this is committed. I tried to indicate what new features need to be
reflected in the manual, when I saw them in your patches (but I'm not
sure I saw all of them).
Also, I think this features should be mentioned in NEWS.
> The patches has direct effect on two user commands. The "info break"
> now outputs multiple locations, if they are present, like this:
>
> Num Type Disp Enb Address What
> 1 breakpoint keep y <MULTIPLE>
> 1.1 y 0xb7fa756d in int bar<int>(int) at helper.hpp:4
> 1.2 y 0xb7fa7588 in double bar<double>(double) at helper.hpp:4
As I wrote in one of my messages, the "1.2" thing could potentially
break alignment of the display. I think we should handle that
somehow.
Also, I'm not convinced that 1.2 is the best possible way to express
what you want, because it looks like a floating-point number. Maybe
we should explicitly have an additional "Loc" column, and format the
list like this:
Num Loc Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1 1 y 0xb7fa756d in int bar<int>(int) at helper.hpp:4
1 2 y 0xb7fa7588 in double bar<double>(double) at helper.hpp:4
> 1 breakpoint keep y <MULTIPLE>
> breakpoint already hit 2 times
> 1.1 y(p) 0xb7f9856d helper.hpp:4
> 1.2 n(p) 0xb7f98588 helper.hpp:4
>
> means that user wants location 1.1 to be enabled, and wants location 1.2
> to be disabled. The "(p)" means that both are in unloaded shared library,
> so naturally 1.1 won't be hit until the library is loaded.
I think the old <PENDING> was much more clear than this enigmatic
"(p)".
Thanks again for working on this.