From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91708 invoked by alias); 2 May 2018 18:42:27 -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 91694 invoked by uid 89); 2 May 2018 18:42:26 -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=bulb, HTo:U*pmuldoon, Phil, Hx-languages-length:1469 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 18:42:25 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C1EF4406C744; Wed, 2 May 2018 18:42:23 +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 B9E7E2022EE0; Wed, 2 May 2018 18:42:22 +0000 (UTC) Subject: Re: Multiple locations and breakpoints confusion. To: Phil Muldoon , Joel Brobecker References: <0627f9db-dc6e-ec75-bfd4-b3cb3cdc1251@redhat.com> <8a04e8e4-b08e-32d0-b44b-efc6f3917878@redhat.com> <83y3h2oztv.fsf@gnu.org> <83po2eow5u.fsf@gnu.org> <20180502164848.zamujdyebvuoxvzr@adacore.com> <30233401-09ff-194c-d39f-b42dde9e423c@redhat.com> Cc: Eli Zaretskii , gdb@sourceware.org From: Pedro Alves Message-ID: <9464193b-2dc9-21f3-0c5a-49a8eb753da2@redhat.com> Date: Wed, 02 May 2018 18:42: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: <30233401-09ff-194c-d39f-b42dde9e423c@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00012.txt.bz2 On 05/02/2018 07:18 PM, Phil Muldoon wrote: > On 02/05/18 17:48, Joel Brobecker wrote: >>> But if you ask me, the current output is immediately >>> understandable. I'd go for updating the manual. >> >> FWIW, that was my thinking also when I first started reading this thread. >> > > I have no real strong opinions -- my purpose was to make sure the > functionality of the upcoming multiple locations patchlet for Python > breakpoints reflected that of GDB. However, seeing (y) in one of > locations of a multiple location breakpoint, even when the main or > parent breakpoint is disabled, does display contradictory > information. I understand the logic of the parent breakpoint > enablement or disablement overriding that of each location, though, > but I also can't help but think it is unclear or ambiguous to the > user when one of the locations says it is enabled when it isn't. It's only contradictory if you think of it like the final or output state, which it is not. Think of it like the state of an _input_ switch instead. Like, if we were talking about a light circuit: [mains switch] - [light switch] - [light bulb] open/closed open/closed on/off The breakpoint enablement is like the mains switch's state. The location's enablement is like the light switch's state. Open any of the switches, and the light turns off. There's no equivalent for light on/off (the final state). Thanks, Pedro Alves