Re: [PATCH 0/2] info breakpoints improvements

[Eli Zaretskii <eliz@gnu.org>]

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

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.