Re: Multiple locations and breakpoints confusion.

[Pedro Alves <palves at redhat dot com>]

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