From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91877 invoked by alias); 1 May 2018 19:32:32 -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 91843 invoked by uid 89); 1 May 2018 19:32:31 -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=HTo:U*gdb, phil, H*r:sk:gdb@sou, Phil 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; Tue, 01 May 2018 19:32:30 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2E88B8DC3F for ; Tue, 1 May 2018 19:32:29 +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 AE65150336; Tue, 1 May 2018 19:32:28 +0000 (UTC) Subject: Re: Multiple locations and breakpoints confusion. To: Phil Muldoon , gdb References: <0627f9db-dc6e-ec75-bfd4-b3cb3cdc1251@redhat.com> From: Pedro Alves Message-ID: <8a04e8e4-b08e-32d0-b44b-efc6f3917878@redhat.com> Date: Tue, 01 May 2018 19:32: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: <0627f9db-dc6e-ec75-bfd4-b3cb3cdc1251@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-05/txt/msg00001.txt.bz2 On 05/01/2018 09:15 AM, Phil Muldoon wrote: > > And indeed that breakpoint is not enabled. If I disable the "parent" breakpoint: > > (gdb) disable 1 > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep n > 1.1 n 0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10 > 1.2 y 0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15 > > It shows 1 as disabled but 1.2 as enabled. That seems wrong to me. In > fact, all of the breakpoints are disabled as evidenced by: > > (gdb) r > Starting program: /home/pmuldoon/outgoing/multiple > [Inferior 1 (process 17661) exited normally] > (gdb) IMO, it's working as intended. A location's actual enablement is determined by: is_enabled(bp) && is_enabled(bp.location) That's basically what the code does, in breakpoint.c:should_be_inserted. The advantage IMO is that this way, when you re-enable the (parent) breakpoint, you don't have to re-disable the individual bp locations that you don't care about, again, because gdb remembers the enable/disabled status of the individual bp locations. > > So in recreating multiple location management in Python, I'm a bit > confused if disabling the parent breakpoint should disable all > locations and there's a display buglet on "info breakpoints", or if > the "info breakpoints" output is correct and there's a breakpoint > buglet regarding the disabling of breakpoints? IMO, it's working as intended. 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. A couple ideas: 1 breakpoint keep y 1.1 y.n 0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10 1.2 y.y 0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15 1 breakpoint keep n 1.1 n.n 0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10 1.2 n.y 0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15 or: 1 breakpoint keep y 1.1 n 0x00000000004004b3 in multiple_test::foo(int) at multiple.cpp:10 1.2 y 0x00000000004004c3 in multiple_test::foo(double) at multiple.cpp:15 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 I think I kind of like the second better, though not sure if it helps more than it confuses. In any case, the relevant sections in the manual could use some clarification. Thanks, Pedro Alves