From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21256 invoked by alias); 25 Mar 2003 16:29:36 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 21249 invoked from network); 25 Mar 2003 16:29:35 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 25 Mar 2003 16:29:35 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h2PGTZQ13404 for ; Tue, 25 Mar 2003 11:29:35 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h2PGTYQ25344 for ; Tue, 25 Mar 2003 11:29:34 -0500 Received: from cygbert.vinschen.de (vpn50-10.rdu.redhat.com [172.16.50.10]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h2PGTX503813 for ; Tue, 25 Mar 2003 08:29:33 -0800 Received: (from corinna@localhost) by cygbert.vinschen.de (8.11.6/8.9.3/Linux sendmail 8.9.3) id h2PGTT524650 for gdb@sources.redhat.com; Tue, 25 Mar 2003 17:29:29 +0100 Date: Tue, 25 Mar 2003 16:29:00 -0000 From: Corinna Vinschen To: gdb@sources.redhat.com Subject: gdb.base/scope.exp problems and possible fix Message-ID: <20030325162929.GG23762@cygbert.vinschen.de> Reply-To: gdb@sources.redhat.com Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-03/txt/msg00336.txt.bz2 Hi, I have a problem with the gdb.base/scope.exp test. I'm getting 100 errors when running this test now for xstormy16-elf while the same test was no problem when I tested xstormy the last time (well, more than 12 months ago). Basically the problem is that: 1 bar() {} 2 3 foo() 4 { 5 int local = 0; 6 7 { 8 int local = 1; 9 bar(); 10 } 11 } When stepping to the call to bar(), `print local' prints correctly "1". When stepping into bar(), then changing the frame with `up' and then calling `print local', it incorrectly prints "0". I've set a breakpoint to dwarf2_evaluate_loc_desc() to see which variable it tries to access: When in the outer block of foo(), var->line is 5, so the correct variable is accessed, frame->frame is 292. The value returned is 0. When in the inner block of foo(), var->line is 8, still the correct variable is accessed, frame->frame is 292. The value returned is 1. After stepping into bar() and calling "up", var->line is 8. So apparently it still thinks it accesses the right variable, frame->frame is still 292... but the returned value is nevertheless 0. Further debugging showed the following difference: While in foo(), the value of the FP register is obviously taken from the register itself. When in the bar(),"up" situation, the FP register is in saved_regs of the next frame. Now, what happens is in execute_stack_op(), when evaluating the content of the FP register, the call to result = (ctx->read_reg) (ctx->baton, op - DW_OP_reg0, &expr_lval, &memaddr); (which is a call to dwarf_expr_read_reg()) returns in both cases the correct result 292 but when in foo(), expr_lval is lval_register, while when in bar(), expr_lval is lval_memory. In the latter case, the correct value in result is ignored and overwritten with the wrong value from memaddr, which is 296. Then, in the calling function (which is the DW_OP_fbreg part of execute_stack_op(), `result' is totally differently handled, with result becoming an illegal value. The 0 printed for `local' isn't actually the 0 from the outer `local' variable but only 0 coincidentally. If in that situation the result value would have been used and treated like a lval_register, everything would have been fine! But as it is now, result is wrongly tweaked twice in execute_stack_op(). I did the following as workaround: Index: dwarf2expr.c =================================================================== RCS file: /cvs/cvsfiles/devo/gdb/dwarf2expr.c,v retrieving revision 2.1 diff -u -p -r2.1 dwarf2expr.c --- dwarf2expr.c 2003/03/19 23:00:23 2.1 +++ dwarf2expr.c 2003/03/25 14:13:55 @@ -367,6 +367,7 @@ execute_stack_op (struct dwarf_expr_cont result = (ctx->read_reg) (ctx->baton, op - DW_OP_reg0, &expr_lval, &memaddr); +#if 0 if (expr_lval == lval_register) { ctx->regnum = op - DW_OP_reg0; @@ -374,6 +375,10 @@ execute_stack_op (struct dwarf_expr_cont } else result = memaddr; +#else + ctx->regnum = op - DW_OP_reg0; + ctx->in_reg = 1; +#endif This solved the scope problem totally *and* solved various other FAILs, too, even in gdb.c++. This one change dropped the overall FAIL count in my local sandbox from 249 to 95! But is that workaround a valid fix? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen@redhat.com