Re: [0/9] Breakpoints at multiple locations

[Eli Zaretskii <eliz@gnu.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.