Re: [0/9] Breakpoints at multiple locations

[Vladimir Prus <vladimir at codesourcery dot com>]

Eli Zaretskii wrote:

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

I'll take care of this after code details are sorted out.

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

I don't find that confusing, but it's me. 

> 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


This way, you'll have "Loc" column even if there are no multi-location
breakpoints. I'm not sure I like this.

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

I believe you're comparing different things. The <PENDING> is the output
in address field, when no address at all was ever established for the breakpoint.
With my patches, you'll still see this in address field for a freshly created
pending breakpoint.

The "(p)" comes to play when you already have a breakpoint, and the library it's
in is unloaded. Then, you have old address, but the breakpoint won't actually be hit.
Old code has three breakpoint enablement states -- "y", "n", and "p".
New code has "y", "n", "y(p)", and "n(p)". It seems to me that (p) is no more
enigmatic than "p". And the benefit is that we don't mess with "enabled/disabled" state
that the user can set. 

To clarify, below is the examples of "info break" output for various cases:

For a freshly added pending breakpoint (zero locations yet):

        Num Type           Disp Enb  Address    What
        1   breakpoint     keep y(p) <PENDING>  f

When that breakpoint is resolved, we naturally get this:

        Num Type           Disp Enb  Address    What
        1   breakpoint     keep y    0xb7ee5412 in f at bp3b.c:7

When the library is unloaded, we'll get:

        Num Type           Disp Enb  Address    What
        1   breakpoint     keep y(p) 0xb7fb6412 bp3b.c:7

For a multiple breakpoint location, once it's resolved, we'll get 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

We can disable one location, to get 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                     n    0xb7fa7588 in double bar<double>(double) at helper.hpp:4

Once the library is unloaded, we get:

        Num Type           Disp Enb  Address    What
        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


Hope this clarifies.

- Volodya