From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17118 invoked by alias); 3 May 2011 16:09:21 -0000 Received: (qmail 17090 invoked by uid 22791); 3 May 2011 16:09:20 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 May 2011 16:09:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C65F92BAE51; Tue, 3 May 2011 12:09:03 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5DI+qs9RoXvk; Tue, 3 May 2011 12:09:03 -0400 (EDT) Received: from kwai.gnat.com (kwai.gnat.com [205.232.38.4]) by rock.gnat.com (Postfix) with ESMTP id 9FB272BAE4D; Tue, 3 May 2011 12:09:03 -0400 (EDT) Received: by kwai.gnat.com (Postfix, from userid 4240) id 8F7C392A54; Tue, 3 May 2011 12:09:03 -0400 (EDT) Date: Tue, 03 May 2011 16:09:00 -0000 From: Jerome Guitton To: Jan Kratochvil Cc: Pedro Alves , gdb-patches@sourceware.org, Tom Tromey , Sergio Durigan Junior Subject: Re: [PATCH 2/6] Introduce `pre_expanded sals' Message-ID: <20110503160903.GA27067@adacore.com> References: <201104121218.08910.pedro@codesourcery.com> <20110412115308.GA384@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110412115308.GA384@host1.jankratochvil.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00065.txt.bz2 Jan Kratochvil (jan.kratochvil@redhat.com): > With the "new" (for some years) syntax `enable X.Y' ane `disable X.Y' one can > control which breakpoints are active easily. > > (gdb) break C::C > Breakpoint 1 at 0x7d1: file ./gdb.cp/re-set-overloaded.cc, line 22. > Breakpoint 2 at 0x7ba: file ./gdb.cp/re-set-overloaded.cc, line 21. (2 locations) > warning: Multiple breakpoints were set. > Use the "delete" command to delete unwanted breakpoints. > (gdb) disable 2.2 > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0x00000000000007d1 in C::C(int) at ./gdb.cp/re-set-overloaded.cc:22 > 2 breakpoint keep y > 2.1 y 0x00000000000007ba in C::C() at ./gdb.cp/re-set-overloaded.cc:21 > 2.2 n 0x00000000000007c4 in C::C() at ./gdb.cp/re-set-overloaded.cc:21 > > So that `set multiple-symbols ask' could be removed (probably > completely incl. the `cancel' option). On the contrary, I was wondering if a proper use of the 'ask/all' option was not precisely the solution here. 'all' would mean: break on any location that matches the linespec given by the user. If a dll is loaded that have a location that matches this linespec, then add a new location for this breakpoint. On 'ask', you would be asked only for instances that have a different canonical location, e.g. (break) C::C [0] cancel [1] all [2] C::C() at ./gdb.cp/re-set-overloaded.cc:21 [3] C::C(int) at ./gdb.cp/re-set-overloaded.cc:22 > Choosing 'all' would trigger a multi-location breakpoint and behave like above. Selecting some would generate different single-location breakpoints on the canonical location. We may even have a command to edit an "all" breakpoint and convert it into a list of selected single-location breakpoints. It may be easier to manage than 3-tiers. (break) breakpoint-edit 1 [0] cancel [1] all [2] C::C() at ./gdb.cp/re-set-overloaded.cc:21 [3] C::C(int) at ./gdb.cp/re-set-overloaded.cc:22 > Now Tom's question remains: what happens if a unambiguous breakpoint location becomes ambiguous at dll load? I would suppose that the appropriate behavior would depend on the 'all/ask' setting: 'all' means all, so new locations are added, the breakpoints, becomes a multi-location breakpoint. 'ask' is the main problem. the appropriate behavior would certainly be to ask the user if the breakpoint should become 'all' or should be canonicalized. The second option could be a problem, I suppose. A compromise would be to convert inconditionally to 'all' with a warning, letting the user edit the breakpoint latter to convert it into selected single-location breakpoints if he/she wants. > I find the current two kinds of multiple breakpoints confusing to users (at > least to myself). I can only agree. From a user point of view, I feel that homonyms, generics and inlining should be handled the same way; the distinction that I need is the 'all/ask' one: either I break on all locations of a breakpoint (homonyms, generic, inlining, whatever), and add any new location that a dll load would bring; or I want to select some of them (presumably one) and have breakpoints on these ones only, and never add new breakpoints if new occurences are brought by a dll.