From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5907 invoked by alias); 15 Sep 2003 19:00:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5898 invoked from network); 15 Sep 2003 19:00:56 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 15 Sep 2003 19:00:56 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id E3608D2DAF; Mon, 15 Sep 2003 12:00:54 -0700 (PDT) Date: Mon, 15 Sep 2003 19:00:00 -0000 From: Joel Brobecker To: Jim Blandy Cc: Andrew Cagney , Paul Koning , gdb-patches@sources.redhat.com Subject: Re: [RFA] parse and eval breakpoint conditions with correct language Message-ID: <20030915190054.GG15984@gnat.com> References: <20030910015400.GS423@gnat.com> <20030911180920.GD945@gnat.com> <16224.49692.542476.869174@gargle.gargle.HOWL> <20030911192958.GE945@gnat.com> <3F612249.7060102@redhat.com> <20030912054651.GI945@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-09/txt/msg00333.txt.bz2 > What gives me pause, though, is that the breakpoint_re_set_one isn't > calling parse_exp_1 directly --- it's calling decode_line_1. Are you > going to propagate the language all the way through there? Yes, it's the only approach I see. > How do you see approaching this? I think the safest way to approach this is by working from the bottom to the top, in tiny steps that should be backward compatible in terms of functionality. Let's define the objectives: 1. We want parse_exp_1 to take a language argument, so that it can use it to do the expression parsing. 2. We want to take advantage of it when parsing a breakpoint condition For that, we need to be able to determine the language associated to a given block (or a given PC, whatever is more convenient) 3. We want to take advantage of 1 to make sure we use the same language everytime we reparse the condition. 4. We want decode_line_1 to take a language argument too, so that when we reset the breakpoints, we can use the same language as the language that was used when the breakpoint was first created. 5. We want to fix the watchpoint problem that we also noticed. I think these 5 steps can be done separately. Here is the plan: 1. Add a language parameter to parse_exp_1. If NULL, then use current_language. Fix all the calls the parse_exp_1 to use NULL. As is, this change should be a nop. 2. Pass the appropriate language to parse_exp_1 in the instances where we parse a condition. That includes modifying condition_command(), break_command_1(), do_captured_breakpoints(). These changes are self-contained, as these procedures can determine on their own the appropriate language. This should fix the original problem I reported. 3. Fix the call to parse_exp_1 in breakpoint_re_set_one to use the same language to reparse the condition. This is also self-contained. 4. a. Add a language argument to decode_line_1() using the same nop approach as for 1. b. Fix the call to decode_line_1 in breakpoint_re_set_one so that the appropriate language is used to parse the given expression. That will allow us to remove the call to set_language, and will make sure that the second problem that I reported will not re-appear. 5. Fix the problem of the wrong language used to reinsert watchpoints. For that we need to do: a. Add a language paramter to parse_expression(). Same as 1. b. Fix the call to parse_expression in breakpoint_re_set_one() to use the same language as before when reparsing the watchpoint expression. The downside is that we will not end up reviewing the entire calling tree to parse_exp_1, so we may leave some problems behind. But whatever problems they are, we will be no worse than before. And the upside is that a lot of the changes should be mechanical, and most of the patches should be reasonably small and easy to review. Shall I do that? -- Joel