Re: [RFA] Fix breakpoint condition that use member variables.

[Michael Snyder <msnyder@specifix.com>]

On Mon, 2008-03-24 at 22:17 +0200, Eli Zaretskii wrote:
> > From: Michael Snyder <msnyder@specifix.com>
> > Cc: Daniel Jacobowitz <drow@false.org>, 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 <drow@false.org>
> > > > Cc: Vladimir Prus <vladimir@codesourcery.com>,
> > > > 	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.