Re: [PATCH 0/2] info breakpoints improvements

[Pedro Alves <pedro@palves.net>]

On 2022-05-24 15:25, Eli Zaretskii wrote:
>> Date: Tue, 24 May 2022 15:09:30 +0100
>> Cc: luis.machado@arm.com, gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>>> I don't understand why would that be lost.  I'm not proposing to
>>> actually disable each location, I propose to _display_ them as
>>> disabled in that case.
>>
>> If you do that, then you're hiding information for no good reason, IMO.
> 
> From my POV, it's the other way around: we will be showing the user
> the actual current behavior of that location.
> 
>> It makes
>> it confusing, one would no longer be able to tell which locations would be enabled
>> once you re-enable the parent breakpoint.  You'd make "enable 3.2" seem to have
>> no effect on a disabled breakpoint, as "info break" would still show the location
>> as disabled.
> 
> Why is this an important use case?  
> It sounds much more useful and
> frequent to first enable the whole breakpoint, and only then enable or
> disable some of its particular locations.  As long as the breakpoint
> is disabled, the internal status of enabled/disabled of its location
> is not important at all.

It is important to be able to look at the breakpoint list and understand that
some locations will be re-enabled once you enable the breakpoint, and which
those are.  We may want to present the enabled locations slightly differently
when the parent breakpoint is disabled, but I disagree with showing them as
disabled in the same way you would show them if the user had disabled them
explicitly.

I think we're going in circles now.

> 
> This is a user-level command, not a "maint" command.  So what is of
> utmost importance is how this will actually behave, not what the
> software's internal state is.

A locations enable/disable state is not internal state, it is user-visible
state that the user can control.  I don't understand why you are bringing
up such an odd "maint" command argument.