From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46400 invoked by alias); 2 May 2018 16:42:09 -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 46385 invoked by uid 89); 2 May 2018 16:42:08 -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,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:gdb@sou, cents, Hx-languages-length:1049, nonetheless X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 May 2018 16:42:07 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BBC6830BC114 for ; Wed, 2 May 2018 16:42:06 +0000 (UTC) Received: from theo.uglyboxes.com (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8FD4860172 for ; Wed, 2 May 2018 16:42:06 +0000 (UTC) Subject: Re: Multiple locations and breakpoints confusion. To: gdb@sourceware.org References: <0627f9db-dc6e-ec75-bfd4-b3cb3cdc1251@redhat.com> <8a04e8e4-b08e-32d0-b44b-efc6f3917878@redhat.com> <83y3h2oztv.fsf@gnu.org> From: Keith Seitz Message-ID: <661b4657-859b-b815-269e-76a1fd30d301@redhat.com> Date: Wed, 02 May 2018 16:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00008.txt.bz2 On 05/02/2018 09:27 AM, Pedro Alves wrote: > (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. While I don't find this confusing at all, I can certainly understand how a user might get a little confused. Nonetheless, if we did want to mitigate the situation, we could add a UI-related tweak, such as adding a new column (yuck) or some sort of "footnote" explaining that the sub-location is currently disabled because the parent is disabled. That would be a pretty simple change to the code base (but probably would have rather severe repercussions on the test suite to deal with). Just my 10E-30 cents, Keith