From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id D0B0C3857340 for ; Tue, 24 May 2022 14:25:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D0B0C3857340 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntVTl-0000A8-2G; Tue, 24 May 2022 10:25:45 -0400 Received: from [87.69.77.57] (port=4896 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ntVTg-00071q-Dh; Tue, 24 May 2022 10:25:42 -0400 Date: Tue, 24 May 2022 17:25:29 +0300 Message-Id: <835ylv57om.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: luis.machado@arm.com, gdb-patches@sourceware.org In-Reply-To: <9cddada4-6572-7bb2-736e-3662097be07e@palves.net> (message from Pedro Alves on Tue, 24 May 2022 15:09:30 +0100) Subject: Re: [PATCH 0/2] info breakpoints improvements References: <20220519215552.3254012-1-pedro@palves.net> <70ddb0b0-7c7d-3bcd-ef3d-246290ae1edf@arm.com> <1e932144-4f4d-4c10-bbaa-deef05684895@palves.net> <83fskz5aol.fsf@gnu.org> <0247c63e-189d-0a71-8b5f-257fd83ff6a3@palves.net> <83czg359mz.fsf@gnu.org> <45d7d87f-f78a-7c6b-28d7-285beecf9a8a@palves.net> <83bkvn58pe.fsf@gnu.org> <9cddada4-6572-7bb2-736e-3662097be07e@palves.net> X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2022 14:25:47 -0000 > Date: Tue, 24 May 2022 15:09:30 +0100 > Cc: luis.machado@arm.com, gdb-patches@sourceware.org > From: Pedro Alves > > > 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.