From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6304 invoked by alias); 22 Mar 2008 13:20:20 -0000 Received: (qmail 6296 invoked by uid 22791); 22 Mar 2008 13:20:20 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Mar 2008 13:20:02 +0000 Received: (qmail 14889 invoked from network); 22 Mar 2008 13:20:00 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Mar 2008 13:20:00 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: [RFA] Fix breakpoint condition that use member variables. Date: Sat, 22 Mar 2008 13:20:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <200803221240.16230.vladimir@codesourcery.com> <200803221536.07586.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803221620.10176.vladimir@codesourcery.com> 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/msg00333.txt.bz2 On Saturday 22 March 2008 15:55:42 Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Sat, 22 Mar 2008 15:36:06 +0300 > > Cc: gdb-patches@sources.redhat.com > > > > > What will happen after your patch if there's also a variable i_ > > > in the selected frame? > > > > The i_ in the breakpoint condition will be associated with the > > member variable, not with the variable with selected frame. > > 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? The current behaviour was around for some time, and my patch only fixes one corner case that is not consistent with the existing behaviour. To answer your question -- I'm not sure. I think it would be wrong for parse_exp_1 -- which is passed explicit block, to go around looking at other blocks it was not asked for. We probably can get block of selected frame, call parse_exp_1 again, in that block, and then walk over two parse results, reporting variables which are bound to different blocks. This sounds like some substantial amount of work, though. - Volodya