From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25476 invoked by alias); 24 Mar 2008 20:18:15 -0000 Received: (qmail 25467 invoked by uid 22791); 24 Mar 2008 20:18:14 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 24 Mar 2008 20:17:47 +0000 Received: from HOME-C4E4A596F7 (IGLD-84-228-236-188.inter.net.il [84.228.236.188]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id JNW01934 (AUTH halo1); Mon, 24 Mar 2008 22:15:12 +0200 (IST) Date: Mon, 24 Mar 2008 20:18:00 -0000 Message-Id: From: Eli Zaretskii To: Michael Snyder CC: drow@false.org, vladimir@codesourcery.com, gdb-patches@sources.redhat.com In-reply-to: <1206381927.19253.1102.camel@localhost.localdomain> (message from Michael Snyder on Mon, 24 Mar 2008 11:05:27 -0700) Subject: Re: [RFA] Fix breakpoint condition that use member variables. Reply-to: Eli Zaretskii References: <200803221240.16230.vladimir@codesourcery.com> <200803221536.07586.vladimir@codesourcery.com> <20080322144931.GA19219@caradoc.them.org> <1206381927.19253.1102.camel@localhost.localdomain> 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/msg00364.txt.bz2 > 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.