From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16675 invoked by alias); 24 Mar 2008 21:04:16 -0000 Received: (qmail 16662 invoked by uid 22791); 24 Mar 2008 21:04:15 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Mar 2008 21:03:58 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 9C8973C61D; Mon, 24 Mar 2008 14:03:56 -0700 (PDT) Subject: Re: [RFA] Fix breakpoint condition that use member variables. From: Michael Snyder To: Eli Zaretskii Cc: drow@false.org, vladimir@codesourcery.com, gdb-patches@sources.redhat.com In-Reply-To: References: <200803221240.16230.vladimir@codesourcery.com> <200803221536.07586.vladimir@codesourcery.com> <20080322144931.GA19219@caradoc.them.org> <1206381927.19253.1102.camel@localhost.localdomain> Content-Type: text/plain Date: Mon, 24 Mar 2008 21:04:00 -0000 Message-Id: <1206392636.19253.1122.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit 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: 2008-03/txt/msg00367.txt.bz2 On Mon, 2008-03-24 at 22:17 +0200, Eli Zaretskii wrote: > > From: Michael Snyder > > Cc: Daniel Jacobowitz , vladimir@codesourcery.com, gdb-patches@sources.redhat.com > > Date: Mon, 24 Mar 2008 11:05:27 -0700 > > > > On Sat, 2008-03-22 at 19:09 +0200, Eli Zaretskii wrote: > > > > Date: Sat, 22 Mar 2008 10:49:31 -0400 > > > > From: Daniel Jacobowitz > > > > Cc: Vladimir Prus , > > > > gdb-patches@sources.redhat.com > > > > > > > > On Sat, Mar 22, 2008 at 02:55:42PM +0200, Eli Zaretskii wrote: > > > > > That could surprise the user. Is it possible to make an additional > > > > > change to look for possible other interpretations of i_ which are > > > > > currently in scope, and display a warning of some kind if such > > > > > possibilities are found? > > > > > > > > This is how breakpoint conditions have worked as long as I can > > > > remember > > > > > > But we could try make it better, couldn't we? > > > > I should think that the "i_" that's chosen should be the > > one in the scope of the breakpoint, not the one that is in > > scope when the breakpoint is created. > > > > Is that not what Vladimir is saying? > > I don't know (I'm not Vladimir), but that's not *exactly* what I was > saying. Imagine the situation where: you have the inferior stopped in > a function that lives in a module which has a variable i_ in global > scope. You decide to place a breakpoint in some other function in the > same module, and condition it on i_. So far so good; however, > unbeknownst to you, there's also a local variable i_ in the function > where you put the breakpoint. How can this be unbeknownst, you ask? > easy: suppose you not really look into that function, just see its > call, and want to step through it. > > IOW, the use case I was thinking of is when i_ happens to be in scope > both when you set the breakpoint _and_ when it breaks. OK, but if that's an issue, it's always been an issue. The present behavior is that the 'i_' that's local to the scope of the breakpoint wins. Vladimir's change just makes it more consistant, in that the 'i_ that's in the breakpoint scope still wins, but now it wins even if it's in the "class" scope of the breakpoint, not just the automatic scope.