gdb.base/scope.exp problems and possible fix

[Corinna Vinschen <vinschen@redhat.com>]

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