From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eliz@gnu.org>
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10])
 by sourceware.org (Postfix) with ESMTPS id 244403857340
 for <gdb-patches@sourceware.org>; Tue, 24 May 2022 13:43:29 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 244403857340
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36860)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1ntUoq-0000R2-C0; Tue, 24 May 2022 09:43:28 -0400
Received: from [87.69.77.57] (port=2310 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@gnu.org>)
 id 1ntUop-00055p-Sa; Tue, 24 May 2022 09:43:28 -0400
Date: Tue, 24 May 2022 16:43:16 +0300
Message-Id: <83czg359mz.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Pedro Alves <pedro@palves.net>
Cc: luis.machado@arm.com, gdb-patches@sourceware.org
In-Reply-To: <0247c63e-189d-0a71-8b5f-257fd83ff6a3@palves.net> (message from
 Pedro Alves on Tue, 24 May 2022 14:29:27 +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>
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 <gdb-patches.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>,
 <mailto:gdb-patches-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 13:43:30 -0000

> Date: Tue, 24 May 2022 14:29:27 +0100
> Cc: luis.machado@arm.com, gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> On 2022-05-24 14:20, Eli Zaretskii wrote:
> >> Date: Tue, 24 May 2022 11:02:07 +0100
> >> From: Pedro Alves <pedro@palves.net>
> >>
> >> Note how breakpoint 4 is disabled, but since all the locations are enabled, the "n" doesn't stand out all that much.
> > 
> > I'm confused: what is the meaning of having a breakpoint disabled,
> > while all of its locations are enabled?  Under which conditions will
> > such a breakpoint break?
> > 
> 
> A location only breaks if it is enabled, _and_ its parent is enabled, so never.

That's what I thought.  But then why not "propagate" the "n" of the
disabled breakpoint to all of its locations?  That way

  (gdb) info break 4.10

will show the truth, no?

I also wonder whether we should display something special on the
"header row" instead of "y" or "n" when some of the locations are
enabled and others aren't.  How about "p" (for "partial") or maybe
"y/n"?