From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128385 invoked by alias); 2 May 2018 18:18:12 -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 128364 invoked by uid 89); 2 May 2018 18:18:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=phil, overriding X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 May 2018 18:18:09 +0000 Received: by mail-wr0-f176.google.com with SMTP id v60-v6so15006318wrc.7 for ; Wed, 02 May 2018 11:18:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wSGVKtJGIE7vGAx2pQ/dgh+erM3Pc5WMcELUN6xsOGk=; b=O2UJzrZ6ypSqcYBNK+dapezz24FLdpXXVAhiXc2pySxZ9uQ63TAqZ7ToRrxjKwjwFv A2VbxfG7gTEoLb3jvBePGfCmpHHzfeCtnP4JzNt2l6/QHDgcF/hSDSYAwiKLsnMTg/Bh YFssp7p2gLTxJlMpkwMW6m6p5iRhT5oS8/j7QZQjVgdEa6HaW+iI8jTJWbdpFdoLuvS1 96cjyr3plmcs73BwpBQuoy6X0U0q+8PWhzdl3Buodo9XNHsUdSvFGmRbkovhb69Lp0WC D4/5k/R9UfTDGLKHy1pgIKo4W4oq5q7WA+OlZ6do3Res8ll/drgeBC9/DBr6KOKor5n1 vBjQ== X-Gm-Message-State: ALQs6tDCEoXG9kntirpQ7dvwL11bAtYROEqXSieBfEjg9htaM/iHj2Gq 9oSopgDac6fXTIjynidFGudha86jKUQ= X-Google-Smtp-Source: AB8JxZo4DY98P5loCnUaRUFJwrbawWI6uVa5qfZgO48W1Y4nUSV+UW/2jiaSC4ZuwAJ2djioSabc2w== X-Received: by 2002:adf:b611:: with SMTP id f17-v6mr16727902wre.139.1525285087521; Wed, 02 May 2018 11:18:07 -0700 (PDT) Received: from ?IPv6:2a02:c7f:ae6a:ed00:4685:ff:fe66:9f4? ([2a02:c7f:ae6a:ed00:4685:ff:fe66:9f4]) by smtp.gmail.com with ESMTPSA id 123sm13724439wmt.19.2018.05.02.11.18.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 11:18:06 -0700 (PDT) Subject: Re: Multiple locations and breakpoints confusion. To: Joel Brobecker , Pedro Alves Cc: Eli Zaretskii , gdb@sourceware.org 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> From: Phil Muldoon Message-ID: <30233401-09ff-194c-d39f-b42dde9e423c@redhat.com> Date: Wed, 02 May 2018 18:18:00 -0000 MIME-Version: 1.0 In-Reply-To: <20180502164848.zamujdyebvuoxvzr@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00011.txt.bz2 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. Cheers Phil