From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69319 invoked by alias); 2 May 2018 15:13:49 -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 67852 invoked by uid 89); 2 May 2018 15:13:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*gdb, letter X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 May 2018 15:13:46 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDtRs-00074S-SY for gdb@sourceware.org; Wed, 02 May 2018 11:13:44 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDtRs-00074O-PG; Wed, 02 May 2018 11:13:40 -0400 Received: from [176.228.60.248] (port=4617 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fDtRs-00052c-5p; Wed, 02 May 2018 11:13:40 -0400 Date: Wed, 02 May 2018 15:13:00 -0000 Message-Id: <83y3h2oztv.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: pmuldoon@redhat.com, gdb@sourceware.org In-reply-to: <8a04e8e4-b08e-32d0-b44b-efc6f3917878@redhat.com> (message from Pedro Alves on Tue, 1 May 2018 20:32:28 +0100) Subject: Re: Multiple locations and breakpoints confusion. Reply-to: Eli Zaretskii References: <0627f9db-dc6e-ec75-bfd4-b3cb3cdc1251@redhat.com> <8a04e8e4-b08e-32d0-b44b-efc6f3917878@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00004.txt.bz2 > 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?