This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Fix breakpoint condition that use member variables.
> From: Michael Snyder <firstname.lastname@example.org>
> Cc: Daniel Jacobowitz <email@example.com>, firstname.lastname@example.org, email@example.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 <firstname.lastname@example.org>
> > > Cc: Vladimir Prus <email@example.com>,
> > > firstname.lastname@example.org
> > >
> > > 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.