public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* gdb.base/scope.exp problems and possible fix
@ 2003-03-25 16:29 Corinna Vinschen
  2003-03-25 16:39 ` Daniel Jacobowitz
  0 siblings, 1 reply; 6+ messages in thread
From: Corinna Vinschen @ 2003-03-25 16:29 UTC (permalink / raw)
  To: gdb

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

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2003-03-31  6:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-25 16:29 gdb.base/scope.exp problems and possible fix Corinna Vinschen
2003-03-25 16:39 ` Daniel Jacobowitz
2003-03-25 16:51   ` Corinna Vinschen
2003-03-25 17:30     ` Corinna Vinschen
2003-03-25 18:28       ` Daniel Jacobowitz
2003-03-31  6:11   ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).