From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IPGrGi7njGJqEwgAWB0awg (envelope-from ) for ; Tue, 24 May 2022 10:09:50 -0400 Received: by simark.ca (Postfix, from userid 112) id 6AA6B1E220; Tue, 24 May 2022 10:09:50 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC 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 DD9111E00D for ; Tue, 24 May 2022 10:09:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7AC5B38F8614 for ; Tue, 24 May 2022 14:09:49 +0000 (GMT) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by sourceware.org (Postfix) with ESMTPS id 64C5A3857340 for ; Tue, 24 May 2022 14:09:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 64C5A3857340 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f52.google.com with SMTP id t6so25907844wra.4 for ; Tue, 24 May 2022 07:09:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=QOywheRTm1vwgUQge7VHbLeUaimfi8+gb9pGUcAaA4A=; b=BOZVG0eMjsRD4wD+Hvuvc1+XH9gScg2+WTvOblvKcWmnNjL2At8mgQNbL4IcBf4G3G mbXO6R/0YTyEhBePmkPoiLjACR1dGUpDCJykHROvjK5DU3iLK46mVEclnjXN88L9dUYW b0i6WOy+tr2AEDFF9PFBLXrgh6mjs+3ktCf1CxGLK5l5UQrr8Dwz/LKzaiZZowubRqvO bYoT3zj7dm29HehH8Zo8sjxRzSUI6xlcbiZ7R+SoG1e3+7kPRqavHOm2lUcfaeFz8MB1 uQYalwdWVkdKWfJJ5acUesFPye2WK3bBOoutr3q25D2//3Kd/ZExEovz+Hdtpgi4Dp7D iv5A== X-Gm-Message-State: AOAM531v24Mi74HYOTXG+9V8U7xGTbFHZYDYheXdAjMjwyFAvASGf/bq Wrcrz4vrH8asgdKHwqFeViMBCZDN/j4= X-Google-Smtp-Source: ABdhPJxUgi/gzl98PT+g/8w5mwwuxCkhalkvqn9mAoDhWlIovRUOKDVNApJxbgigrHDEVnakkJRmXQ== X-Received: by 2002:a5d:6f07:0:b0:20f:e7b6:60e9 with SMTP id ay7-20020a5d6f07000000b0020fe7b660e9mr6441761wrb.452.1653401373369; Tue, 24 May 2022 07:09:33 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id e7-20020adfa447000000b0020fecaecb0fsm3114721wra.50.2022.05.24.07.09.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 May 2022 07:09:32 -0700 (PDT) Message-ID: <9cddada4-6572-7bb2-736e-3662097be07e@palves.net> Date: Tue, 24 May 2022 15:09:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 0/2] info breakpoints improvements Content-Language: en-US To: Eli Zaretskii 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> From: Pedro Alves In-Reply-To: <83bkvn58pe.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-05-24 15:03, Eli Zaretskii wrote: >> Date: Tue, 24 May 2022 14:50:01 +0100 >> Cc: luis.machado@arm.com, gdb-patches@sourceware.org >> From: Pedro Alves >> >>>> 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? >> >> Because then when you re-enable the parent breakpoint, you'd have lost the enabled/disabled >> state of the individual locations. > > 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. 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. > >>> (gdb) info break 4.10 >>> >>> will show the truth, no? >> >> You can't "info break" an individual location. > > And you are certain we never will support that? Of course not, but as usual, we can cross that bridge when to come to it. I suspect that if we did support that, we would still want to print the breakpoint row for breakpoint 4 and then only location 10 (skipping all other locations), so you'd still see the breakpoint's enable state, and other info.