This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
gdb.base/scope.exp problems and possible fix
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 25 Mar 2003 17:29:29 +0100
- Subject: gdb.base/scope.exp problems and possible fix
- Reply-to: gdb at sources dot redhat dot 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 at redhat dot com