From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26504 invoked by alias); 9 Oct 2007 20:17:26 -0000 Received: (qmail 26493 invoked by uid 22791); 9 Oct 2007 20:17:25 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 09 Oct 2007 20:17:21 +0000 Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id l99KHHWR007577 for ; Tue, 9 Oct 2007 21:17:17 +0100 Received: from ug-out-1314.google.com (ugc29.prod.google.com [10.66.3.29]) by zps18.corp.google.com with ESMTP id l99KGSGL030907 for ; Tue, 9 Oct 2007 13:17:16 -0700 Received: by ug-out-1314.google.com with SMTP id 29so184556ugc for ; Tue, 09 Oct 2007 13:17:15 -0700 (PDT) Received: by 10.66.255.7 with SMTP id c7mr1137700ugi.1191961034499; Tue, 09 Oct 2007 13:17:14 -0700 (PDT) Received: by 10.66.242.13 with HTTP; Tue, 9 Oct 2007 13:17:14 -0700 (PDT) Message-ID: Date: Tue, 09 Oct 2007 20:17:00 -0000 From: "Douglas Evans" To: "Vladimir Prus" Subject: Re: template breakpoints Cc: gdb@sources.redhat.com In-Reply-To: <200710092156.39099.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200710090856.29427.ghost@cs.msu.su> <200710092156.39099.vladimir@codesourcery.com> X-IsSubscribed: yes 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/msg00051.txt.bz2 On 10/9/07, Vladimir Prus wrote: > > 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. The phrasing here is a bit confusing. Did you mean per-location here (^^^^) ? [I'm not suggesting an opinion on what it should be, just trying to understand the current plan.] > 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. Thanks. I'm all for a good u/i. At the moment I'm just trying to understand what the plan is going forward. How about breakpoint commands? Are they considered akin to conditions (and thus the plan is to leave them as is)?