Multiple locations and breakpoints confusion.

Multiple locations and breakpoints confusion.

[Phil Muldoon]

Hello all,

I have a very simple test inferior:

class multiple_test
{
public:
  void foo(int f);
  void foo(double f);
};

void multiple_test::foo(int f)
{
  return;
}

void multiple_test::foo(double f)
{
  return;
}


main()
{
  multiple_test m;
  m.foo(2);
  m.foo(2.2);
}

And I place a breakpoint on 'multiple_test::foo'

This results in a breakpoint with two locations (as expected):

(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
1.2                         y     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

Now, If I disable 1.1 it shows (correctly):

(gdb) disable 1.1
(gdb) info breakpoints 
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         n     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
1.2                         y     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

And indeed that breakpoint is not enabled. If I disable the "parent" breakpoint:

(gdb) disable 1
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep n   <MULTIPLE>         
1.1                         n     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
1.2                         y     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

It shows 1 as disabled but 1.2 as enabled. That seems wrong to me. In
fact, all of the breakpoints are disabled as evidenced by:

(gdb) r
Starting program: /home/pmuldoon/outgoing/multiple
[Inferior 1 (process 17661) exited normally]
(gdb)

So in recreating multiple location management in Python, I'm a bit
confused if disabling the parent breakpoint should disable all
locations and there's a display buglet on "info breakpoints", or if
the "info breakpoints" output is correct and there's a breakpoint
buglet regarding the disabling of breakpoints?

Cheers

Phil

Re: Multiple locations and breakpoints confusion.

[Pedro Alves]

On 05/01/2018 09:15 AM, Phil Muldoon wrote:

> 
> And indeed that breakpoint is not enabled. If I disable the "parent" breakpoint:
> 
> (gdb) disable 1
> (gdb) info breakpoints
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep n   <MULTIPLE>         
> 1.1                         n     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
> 1.2                         y     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15
> 
> It shows 1 as disabled but 1.2 as enabled. That seems wrong to me. In
> fact, all of the breakpoints are disabled as evidenced by:
> 
> (gdb) r
> Starting program: /home/pmuldoon/outgoing/multiple
> [Inferior 1 (process 17661) exited normally]
> (gdb)

IMO, it's working as intended.  A location's actual
enablement is determined by:

  is_enabled(bp) && is_enabled(bp.location)

That's basically what the code does, in breakpoint.c:should_be_inserted.

The advantage IMO is that this way, when you re-enable the (parent)
breakpoint, you don't have to re-disable the individual bp locations
that you don't care about, again, because gdb remembers the
enable/disabled status of the individual bp locations.

> 
> So in recreating multiple location management in Python, I'm a bit
> confused if disabling the parent breakpoint should disable all
> locations and there's a display buglet on "info breakpoints", or if
> the "info breakpoints" output is correct and there's a breakpoint
> buglet regarding the disabling of breakpoints?

IMO, it's working as intended.

Maybe it'd help if we would come up with some concise
way to display a location as enabled-but-note-parent-is-disabled
differently, like with a different letter or some extra character
or something like that.  A couple ideas:

 1       breakpoint     keep y   <MULTIPLE>         
 1.1                         y.n   0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
 1.2                         y.y   0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

 1       breakpoint     keep n   <MULTIPLE>         
 1.1                         n.n   0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
 1.2                         n.y   0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

or:

 1       breakpoint     keep y   <MULTIPLE>         
 1.1                         n     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
 1.2                         y     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

 1       breakpoint     keep n   <MULTIPLE>         
 1.1                         (y)   0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
 1.2                         (n)   0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

I think I kind of like the second better, though not sure if it
helps more than it confuses.

In any case, the relevant sections in the manual could
use some clarification.

Thanks,
Pedro Alves

Re: Multiple locations and breakpoints confusion.

[Eli Zaretskii]

> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 1 May 2018 20:32:28 +0100
> 
> IMO, it's working as intended.

I agree that it's working as intended, but I think the UI is
confusing.

> Maybe it'd help if we would come up with some concise
> way to display a location as enabled-but-note-parent-is-disabled
> differently, like with a different letter or some extra character
> or something like that.

If disabling the parent disables all of its children, why not show all
of the children disabled when the parent is disabled?  IOW, why can't
we make the y/n display use the same logic as the one used when
deciding whether a breakpoint at a particular location is disabled?

Re: Multiple locations and breakpoints confusion.

[Pedro Alves]

On 05/02/2018 04:13 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 1 May 2018 20:32:28 +0100
>>
>> IMO, it's working as intended.
> 
> I agree that it's working as intended, but I think the UI is
> confusing.
> 
>> Maybe it'd help if we would come up with some concise
>> way to display a location as enabled-but-note-parent-is-disabled
>> differently, like with a different letter or some extra character
>> or something like that.
> 
> If disabling the parent disables all of its children, why not show all
> of the children disabled when the parent is disabled?  IOW, why can't
> we make the y/n display use the same logic as the one used when
> deciding whether a breakpoint at a particular location is disabled?
That loses information, i.e., one can't tell which ones were explicitly
disabled, and will be re-enabled.  Really can't see why that's better
and more desirable.  And it'd still be confusing to someone -- "why is
it that when I disable the parent, all its locations show as disabled,
but when I enable the parent, only some locations show as enabled,
why not all?" would then be a legitimate question.

Thanks,
Pedro Alves

Re: Multiple locations and breakpoints confusion.

[Pedro Alves]

On 05/02/2018 05:15 PM, Pedro Alves wrote:
> On 05/02/2018 04:13 PM, Eli Zaretskii wrote:
>>> From: Pedro Alves <palves@redhat.com>
>>> Date: Tue, 1 May 2018 20:32:28 +0100
>>>
>>> IMO, it's working as intended.
>>
>> I agree that it's working as intended, but I think the UI is
>> confusing.
>>
>>> Maybe it'd help if we would come up with some concise
>>> way to display a location as enabled-but-note-parent-is-disabled
>>> differently, like with a different letter or some extra character
>>> or something like that.
>>
>> If disabling the parent disables all of its children, why not show all
>> of the children disabled when the parent is disabled?  IOW, why can't
>> we make the y/n display use the same logic as the one used when
>> deciding whether a breakpoint at a particular location is disabled?

> That loses information, i.e., one can't tell which ones were explicitly
> disabled, and will be re-enabled.  Really can't see why that's better
> and more desirable.  And it'd still be confusing to someone -- "why is
> it that when I disable the parent, all its locations show as disabled,
> but when I enable the parent, only some locations show as enabled,
> why not all?" would then be a legitimate question.


To expand on the "losing information" aspect, as an example,
you may want to enable the individual locations of the
breakpoints with the parent breakpoint disabled, then e.g.,
add a condition and commands to the (parent) breakpoint, and then
finally enable the breakpoint.  Not being able to see effect
of the location enablement in the enabled state of locations
in "info breakpoints" while the parent is disabled seems
undesirable to me.  Like e.g.:

 (gdb) disable 1.1-2
 (gdb) disable 1
 (gdb) enable 1.1
 (gdb) info breakpoints 
 Num     Type           Disp Enb Address            What
 1       breakpoint     keep n   <MULTIPLE>         
 1.1                         y     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
 1.2                         n     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15

Here, it seems very desirable to me to be able to tell that
location 1.1 is going to be enabled if I decide to enable breakpoint 1.

Thanks,
Pedro Alves

Re: Multiple locations and breakpoints confusion.

[Eli Zaretskii]

> Cc: pmuldoon@redhat.com, gdb@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Wed, 2 May 2018 17:15:32 +0100
> 
> > If disabling the parent disables all of its children, why not show all
> > of the children disabled when the parent is disabled?  IOW, why can't
> > we make the y/n display use the same logic as the one used when
> > deciding whether a breakpoint at a particular location is disabled?
> That loses information, i.e., one can't tell which ones were explicitly
> disabled, and will be re-enabled.

Providing this information is not the main purpose of that display.
The main purpose is to accurately describe the current state of
affairs.

> Really can't see why that's better and more desirable.

I guess we disagree, then.

My problem with all your alternative suggestions is that they all are
riddles, to some extent: the interpretation of "y.n", "y(n)", etc. is
impossible without reading the manual.  Which is a regression of
sorts, because the simple "y" or "n" display is immediately
understandable by just looking at it.

> And it'd still be confusing to someone -- "why is it that when I
> disable the parent, all its locations show as disabled, but when I
> enable the parent, only some locations show as enabled, why not
> all?" would then be a legitimate question.

And the answer is that the user actually asked for that by her
actions.  So I have no problem with this difficulty.

Re: Multiple locations and breakpoints confusion.

[Keith Seitz]

On 05/02/2018 09:27 AM, Pedro Alves wrote:
>  (gdb) disable 1.1-2
>  (gdb) disable 1
>  (gdb) enable 1.1
>  (gdb) info breakpoints 
>  Num     Type           Disp Enb Address            What
>  1       breakpoint     keep n   <MULTIPLE>         
>  1.1                         y     0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10
>  1.2                         n     0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15
> 
> Here, it seems very desirable to me to be able to tell that
> location 1.1 is going to be enabled if I decide to enable breakpoint 1.

While I don't find this confusing at all, I can certainly understand how a user might get a little confused.

Nonetheless, if we did want to mitigate the situation, we could add a UI-related tweak, such as adding a new column (yuck) or some sort of "footnote" explaining that the sub-location is currently disabled because the parent is disabled.

That would be a pretty simple change to the code base (but probably would have rather severe repercussions on the test suite to deal with).

Just my 10E-30 cents,
Keith

Re: Multiple locations and breakpoints confusion.

[Pedro Alves]

On 05/02/2018 05:32 PM, Eli Zaretskii wrote:
>> Cc: pmuldoon@redhat.com, gdb@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Wed, 2 May 2018 17:15:32 +0100
>>
>>> If disabling the parent disables all of its children, why not show all
>>> of the children disabled when the parent is disabled?  IOW, why can't
>>> we make the y/n display use the same logic as the one used when
>>> deciding whether a breakpoint at a particular location is disabled?
>> That loses information, i.e., one can't tell which ones were explicitly
>> disabled, and will be re-enabled.
> 
> Providing this information is not the main purpose of that display.
> The main purpose is to accurately describe the current state of
> affairs.

The current gdb output describes the current state of affairs.
See my other email.

> 
>> Really can't see why that's better and more desirable.
> 
> I guess we disagree, then.
> 

I agree we disagree.  :-)

> My problem with all your alternative suggestions is that they all are
> riddles, to some extent: the interpretation of "y.n", "y(n)", etc. is
> impossible without reading the manual.  Which is a regression of
> sorts, because the simple "y" or "n" display is immediately
> understandable by just looking at it.

Note it was not "y(n)" that was suggested, but "(y)", as in,
"location is explicitly enabled, but not actually active".

But if you ask me, the current output is immediately
understandable.  I'd go for updating the manual.

> 
>> And it'd still be confusing to someone -- "why is it that when I
>> disable the parent, all its locations show as disabled, but when I
>> enable the parent, only some locations show as enabled, why not
>> all?" would then be a legitimate question.
> 
> And the answer is that the user actually asked for that by her
> actions.  So I have no problem with this difficulty.

The current output is what the user gets too as consequence
of her actions, so I don't see why that serves as argument.
Just different expectations.

Thanks,
Pedro Alves

Re: Multiple locations and breakpoints confusion.

[Joel Brobecker]

> But if you ask me, the current output is immediately
> understandable.  I'd go for updating the manual.

FWIW, that was my thinking also when I first started reading this thread.

-- 
Joel

Re: Multiple locations and breakpoints confusion.

[Phil Muldoon]

On 02/05/18 17:48, Joel Brobecker wrote:
>> But if you ask me, the current output is immediately
>> understandable.  I'd go for updating the manual.
> 
> FWIW, that was my thinking also when I first started reading this thread.
> 

I have no real strong opinions -- my purpose was to make sure the
functionality of the upcoming multiple locations patchlet for Python
breakpoints reflected that of GDB. However, seeing (y) in one of
locations of a multiple location breakpoint, even when the main or
parent breakpoint is disabled, does display contradictory
information. I understand the logic of the parent breakpoint
enablement or disablement overriding that of each location, though,
but I also can't help but think it is unclear or ambiguous to the
user when one of the locations says it is enabled when it isn't.

Cheers

Phil

Re: Multiple locations and breakpoints confusion.

[Pedro Alves]

On 05/02/2018 07:18 PM, Phil Muldoon wrote:
> On 02/05/18 17:48, Joel Brobecker wrote:
>>> But if you ask me, the current output is immediately
>>> understandable.  I'd go for updating the manual.
>>
>> FWIW, that was my thinking also when I first started reading this thread.
>>
> 
> I have no real strong opinions -- my purpose was to make sure the
> functionality of the upcoming multiple locations patchlet for Python
> breakpoints reflected that of GDB. However, seeing (y) in one of
> locations of a multiple location breakpoint, even when the main or
> parent breakpoint is disabled, does display contradictory
> information. I understand the logic of the parent breakpoint
> enablement or disablement overriding that of each location, though,
> but I also can't help but think it is unclear or ambiguous to the
> user when one of the locations says it is enabled when it isn't.
It's only contradictory if you think of it like the final or
output  state, which it is not.  

Think of it like the state of an _input_ switch instead.

Like, if we were talking about a light circuit:

 [mains switch] - [light switch] - [light bulb]
  open/closed      open/closed      on/off

The breakpoint enablement is like the mains switch's state.

The location's enablement is like the light switch's state.

Open any of the switches, and the light turns off.

There's no equivalent for light on/off (the final state).

Thanks,
Pedro Alves