From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20418 invoked by alias); 10 May 2010 19:15:24 -0000 Received: (qmail 20407 invoked by uid 22791); 10 May 2010 19:15:22 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 May 2010 19:15:18 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4AJEtjg021901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 May 2010 15:14:56 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4AJEtop012149; Mon, 10 May 2010 15:14:55 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o4AJEmOe019371; Mon, 10 May 2010 15:14:52 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id A7D1E37818E; Mon, 10 May 2010 13:14:47 -0600 (MDT) From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: [RFC/commit] parse breakpoint condition according to breakpoint location References: <1273427894-4461-1-git-send-email-brobecker@adacore.com> Reply-To: tromey@redhat.com Date: Mon, 10 May 2010 19:15:00 -0000 In-Reply-To: <1273427894-4461-1-git-send-email-brobecker@adacore.com> (Joel Brobecker's message of "Sun, 9 May 2010 19:58:13 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: 2010-05/txt/msg00226.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> So the decision was, if the language is auto, to use the language Joel> corresponding to the breakpoint location, not the current frame. Joel> This is what this patch implements. Sounds reasonable. Joel> ... But at the same time, the discussion digressed over the use of Joel> a global. I proposed a plan for dealing with this, but it's a huge Joel> change (adding a language parameter to the parse_* routines), and Joel> I don't think I got feedback on how I was planning to proceed. For reference the plan is here: http://www.sourceware.org/ml/gdb-patches/2003-09/msg00333.html I would prefer never passing NULL to parse_exp_1 -- just make the callers explicitly pass current_language. That is just a minor detail; overall it sounds fine to me. current_language is a problem global. It is referenced in a lot of places where an argument would be preferable. E.g., even though expressions carry their language, code in valops.c checks the global, so you can wind up with odd behavior (at least in theory, I have not tried to make a reproducer). Probably, evaluate_expression should call set_language and restore the old language in a cleanup -- though this is a workaround and not a clean fix. Joel> Summary of the problem: Joel> For the longer term, this approach is far from perfect, since it Joel> depends on the current_language global, which may change over Joel> time. For instance, if the user switches from language auto to Joel> language c between the moment he creates the breakpoint and the Joel> moment he runs the program, the condition will get re-evaluated Joel> using C the next time around. Once the condition is successfully parsed, it seems to me that any re-parsing should be done with that same language. Maybe this is already accomplished by the set_language calls in breakpoint.c, I'm not sure. Tom