From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RvEzHRThjGL1EQgAWB0awg (envelope-from ) for ; Tue, 24 May 2022 09:43:48 -0400 Received: by simark.ca (Postfix, from userid 112) id 6B0441E220; Tue, 24 May 2022 09:43:48 -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=bm9UWKVg; 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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 F0A821E00D for ; Tue, 24 May 2022 09:43:47 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3498C38293DE for ; Tue, 24 May 2022 13:43:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3498C38293DE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1653399827; bh=42QV5dRVpoVGjLTp1wclKo19RvJOv/wiaxe6aMtRDAo=; 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=bm9UWKVgV5W54/OL7pd53FPvQ+uitgcB8MZqhxPeBmGRivNCCiXdU17Gh3OrjIlBz i9UIz2XYIQL13dTgWQyohmQgQ11rWkWSDDJb5YhJm36rn1ZwmhKbJuKWQGBurkTbo+ X03Eke0w+9k+tPoT6pTIYulPsLOcqfKogNZHQ3co= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 244403857340 for ; 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 ) 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 ) 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> To: Pedro Alves 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-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 14:29:27 +0100 > Cc: luis.machado@arm.com, gdb-patches@sourceware.org > From: Pedro Alves > > On 2022-05-24 14:20, Eli Zaretskii wrote: > >> Date: Tue, 24 May 2022 11:02:07 +0100 > >> From: Pedro Alves > >> > >> 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"?