From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Uh4XK//qjGIaFQgAWB0awg (envelope-from ) for ; Tue, 24 May 2022 10:26:07 -0400 Received: by simark.ca (Postfix, from userid 112) id A065E1E220; Tue, 24 May 2022 10:26:07 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=ElaRzodH; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 7E46C1E00D for ; Tue, 24 May 2022 10:26:05 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 15B68384385C for ; Tue, 24 May 2022 14:26:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 15B68384385C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1653402365; bh=bWs32YP8ZzZjgr+ovgA+Pxv9dbb0siBdoQJoblAUpsQ=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ElaRzodHts1gpgXa7DOc9Iw/gae9nhccOaEGpNElvw4rpJEtTdiDjALvMHD4De5CQ YUTk1M4A4MsV1beu8m44+YgRxqN/qOMFtf79zxWrGEDMmXRGMBPmX0mfU9vtNLcO9k jaDIyYIcsLCtAS6ci70/uKNPA0gVvBOnuoIR71dY= 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> To: Pedro Alves 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-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: , From: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > 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.