From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125938 invoked by alias); 2 May 2018 16:27:15 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 125656 invoked by uid 89); 2 May 2018 16:27:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=losing, Hx-languages-length:2162 X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 May 2018 16:27:13 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 53A5740704BE; Wed, 2 May 2018 16:27:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 66FA8111764D; Wed, 2 May 2018 16:27:11 +0000 (UTC) Subject: Re: Multiple locations and breakpoints confusion. To: Eli Zaretskii References: <0627f9db-dc6e-ec75-bfd4-b3cb3cdc1251@redhat.com> <8a04e8e4-b08e-32d0-b44b-efc6f3917878@redhat.com> <83y3h2oztv.fsf@gnu.org> Cc: pmuldoon@redhat.com, gdb@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 02 May 2018 16:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00006.txt.bz2 On 05/02/2018 05:15 PM, Pedro Alves wrote: > On 05/02/2018 04:13 PM, Eli Zaretskii wrote: >>> From: Pedro Alves >>> Date: Tue, 1 May 2018 20:32:28 +0100 >>> >>> IMO, it's working as intended. >> >> I agree that it's working as intended, but I think the UI is >> confusing. >> >>> Maybe it'd help if we would come up with some concise >>> way to display a location as enabled-but-note-parent-is-disabled >>> differently, like with a different letter or some extra character >>> or something like that. >> >> If disabling the parent disables all of its children, why not show all >> of the children disabled when the parent is disabled? IOW, why can't >> we make the y/n display use the same logic as the one used when >> deciding whether a breakpoint at a particular location is disabled? > That loses information, i.e., one can't tell which ones were explicitly > disabled, and will be re-enabled. Really can't see why that's better > and more desirable. And it'd still be confusing to someone -- "why is > it that when I disable the parent, all its locations show as disabled, > but when I enable the parent, only some locations show as enabled, > why not all?" would then be a legitimate question. To expand on the "losing information" aspect, as an example, you may want to enable the individual locations of the breakpoints with the parent breakpoint disabled, then e.g., add a condition and commands to the (parent) breakpoint, and then finally enable the breakpoint. Not being able to see effect of the location enablement in the enabled state of locations in "info breakpoints" while the parent is disabled seems undesirable to me. Like e.g.: (gdb) disable 1.1-2 (gdb) disable 1 (gdb) enable 1.1 (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep n 1.1 y 0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10 1.2 n 0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15 Here, it seems very desirable to me to be able to tell that location 1.1 is going to be enabled if I decide to enable breakpoint 1. Thanks, Pedro Alves