From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16141 invoked by alias); 9 Oct 2007 17:57:05 -0000 Received: (qmail 16130 invoked by uid 22791); 9 Oct 2007 17:57:04 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 17:57:00 +0000 Received: (qmail 26674 invoked from network); 9 Oct 2007 17:56:58 -0000 Received: from unknown (HELO wind.local) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Oct 2007 17:56:58 -0000 From: Vladimir Prus To: "Douglas Evans" Subject: Re: template breakpoints Date: Tue, 09 Oct 2007 17:57:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb@sources.redhat.com References: <200710090856.29427.ghost@cs.msu.su> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710092156.39099.vladimir@codesourcery.com> 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 X-SW-Source: 2007-10/txt/msg00050.txt.bz2 On Tuesday 09 October 2007 21:44:17 Douglas Evans wrote: > On 10/8/07, Vladimir Prus wrote: > > On Tuesday 09 October 2007 02:35:35 Douglas Evans wrote: > > > Hi. I downloaded and tried the new support. Nice. I noticed that > > > while enable/disable work with the new "multiple breakpoints", > > > condition/ignore/commands don't (currently) work. Is there a plan to > > > support these with the new breakpoints as well? > > > > They are supposed to work. Can you provide a self-contained (source) program, > > and a set of gdb commands that reproduce the problem? > > Appended is the session log. The testcase is testsuite/gdb.cp/mb-templates.cc. > > Note that in breakpoints.cc {enable,disable}_command do a strchr > (args, '.') to watch for a.b spelled breakpoints where as > {commands,ignore,condition}_command just call get_number. And > delete_command calls get_number_or_range via map_breakpoint_numbers. > [Assuming I'm reading the code correctly ...] > > Also, note that by "support" I mean one can, for example, set a > condition on individual breakpoints within the multi-breakpoint(sp?). > [Just making sure we're on the same page ...] Ah, I see what you mean. As it stands now, condition, command, and ignore count is per-breakpoint, not per-location. It was suggested that ignore count and hit count be made per-breakpoint, but was outside the code of the original work. As for condition, I'm not sure. On code level it's not hard to support, but there are issues. First issue is technical. A breakpoint is reevaluated as any shared library is loaded and unloaded. If you set per-location condition, you probably want that condition to be still active after the library containing the location is unloaded and reloaded several time, and application restarted. To do that, we need to somehow track location's identity, and I don't know 100% reliable solution. We have similar problem with enable/disable state, but there, at worst case you'll stop on location you don't care about. With per-location condition, you can just loose your condition. Another issue is "why?". Presumably, if you want a specific condition for just one template instantiation, you can just set breakpoint on that template instatiation? I basically worry that the user interface will become too complex to be usable. - Volodya