From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19089 invoked by alias); 11 Sep 2003 19:30:00 -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 19065 invoked from network); 11 Sep 2003 19:29:59 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 11 Sep 2003 19:29:59 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id AC487D2DAF; Thu, 11 Sep 2003 12:29:58 -0700 (PDT) Date: Thu, 11 Sep 2003 19:30:00 -0000 From: Joel Brobecker To: Paul Koning Cc: jimb@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA] parse and eval breakpoint conditions with correct language Message-ID: <20030911192958.GE945@gnat.com> References: <20030910015400.GS423@gnat.com> <20030911180920.GD945@gnat.com> <16224.49692.542476.869174@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16224.49692.542476.869174@gargle.gargle.HOWL> User-Agent: Mutt/1.4i X-SW-Source: 2003-09/txt/msg00236.txt.bz2 > Could the same sort of trouble occur when evaluating watchpoint > expressions? The parsing should be done according to the language in > effect when the watchpoint is defined (either explicit, or from the > current block language given this patch) -- not the one that happens > to be in effect when gdb is checking for watch hits during execution. That would be an issue that's a bit outside of the context of this patch, but I had a quick look. And we don't seem to consider the language when resetting watchpoints: breakpoint_re_set_one(): case bp_watchpoint: case bp_hardware_watchpoint: case bp_read_watchpoint: case bp_access_watchpoint: innermost_block = NULL; /* The issue arises of what context to evaluate this in. The same one as when it was set, but what does that mean when symbols have been re-read? We could save the filename and functionname, but if the context is more local than that, the best we could do would be something like how many levels deep and which index at that particular level, but that's going to be less stable than filenames or function names. */ /* So for now, just use a global context. */ if (b->exp) xfree (b->exp); b->exp = parse_expression (b->exp_string); I made a small experiment with an Ada program, and it did not go too well :-(. I had to use GDB 5.3 as I don't have under my immediate reach an Ada-aware version of GDB based on the current head sources. But I think the same problem applies there too. % gdb foo (gdb) watch light Hardware watchpoint 1: pck.light (gdb) set lang c (gdb) run Starting program: /[...]/foo Error in re-setting breakpoint 1: No symbol "light" in current context. zsh: 24784 segmentation fault (core dumped) gdb foo The following patch seems to be fixing it, but I would need more time to really think about it more thouroughly. --- breakpoint.c 5 Sep 2003 21:51:24 -0000 1.4 +++ breakpoint.c 11 Sep 2003 19:23:08 -0000 @@ -7089,6 +7089,7 @@ breakpoint_re_set_one (PTR bint) /* So for now, just use a global context. */ if (b->exp) xfree (b->exp); + set_language (b->language); b->exp = parse_expression (b->exp_string); b->exp_valid_block = innermost_block; mark = value_mark (); -- Joel