From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Cc: luis.machado@arm.com, gdb-patches@sourceware.org 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-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 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:09:39 -0000 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.