gdb.base/scope.exp problems and possible fix

gdb.base/scope.exp problems and possible fix

[Corinna Vinschen]

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

Re: gdb.base/scope.exp problems and possible fix

[Daniel Jacobowitz]

On Tue, Mar 25, 2003 at 05:29:29PM +0100, Corinna Vinschen wrote:
> But is that workaround a valid fix?

I don't think it's completely right, but I have good news for you - I
do have a patch that I think _is_ right.  I submitted it for review two
weeks ago.  Would you please try the patch in:
  http://sources.redhat.com/ml/gdb-patches/2003-03/msg00286.html
and tell me whether it works as well for you?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb.base/scope.exp problems and possible fix

[Corinna Vinschen]

Hi Daniel,

On Tue, Mar 25, 2003 at 11:39:31AM -0500, Daniel Jacobowitz wrote:
> On Tue, Mar 25, 2003 at 05:29:29PM +0100, Corinna Vinschen wrote:
> > But is that workaround a valid fix?
> 
> I don't think it's completely right, but I have good news for you - I
> do have a patch that I think _is_ right.  I submitted it for review two
> weeks ago.  Would you please try the patch in:
>   http://sources.redhat.com/ml/gdb-patches/2003-03/msg00286.html
> and tell me whether it works as well for you?

I tested it on scope.exp and it works fine.  Another test on store.exp
which had related errors is running fine, too.

I've just started a full testsuite run to see if it has any regressions
in comparison to my patch.  I'll report back in an hour or so.

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: gdb.base/scope.exp problems and possible fix

[Corinna Vinschen]

On Tue, Mar 25, 2003 at 05:51:39PM +0100, Corinna Vinschen wrote:
> Hi Daniel,
> 
> On Tue, Mar 25, 2003 at 11:39:31AM -0500, Daniel Jacobowitz wrote:
> > On Tue, Mar 25, 2003 at 05:29:29PM +0100, Corinna Vinschen wrote:
> > > But is that workaround a valid fix?
> > 
> > I don't think it's completely right, but I have good news for you - I
> > do have a patch that I think _is_ right.  I submitted it for review two
> > weeks ago.  Would you please try the patch in:
> >   http://sources.redhat.com/ml/gdb-patches/2003-03/msg00286.html
> > and tell me whether it works as well for you?
> 
> I tested it on scope.exp and it works fine.  Another test on store.exp
> which had related errors is running fine, too.
> 
> I've just started a full testsuite run to see if it has any regressions
> in comparison to my patch.  I'll report back in an hour or so.

No regressions!

Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.
mailto:vinschen@redhat.com

Re: gdb.base/scope.exp problems and possible fix

[Daniel Jacobowitz]

On Tue, Mar 25, 2003 at 06:30:38PM +0100, Corinna Vinschen wrote:
> On Tue, Mar 25, 2003 at 05:51:39PM +0100, Corinna Vinschen wrote:
> > Hi Daniel,
> > 
> > On Tue, Mar 25, 2003 at 11:39:31AM -0500, Daniel Jacobowitz wrote:
> > > On Tue, Mar 25, 2003 at 05:29:29PM +0100, Corinna Vinschen wrote:
> > > > But is that workaround a valid fix?
> > > 
> > > I don't think it's completely right, but I have good news for you - I
> > > do have a patch that I think _is_ right.  I submitted it for review two
> > > weeks ago.  Would you please try the patch in:
> > >   http://sources.redhat.com/ml/gdb-patches/2003-03/msg00286.html
> > > and tell me whether it works as well for you?
> > 
> > I tested it on scope.exp and it works fine.  Another test on store.exp
> > which had related errors is running fine, too.
> > 
> > I've just started a full testsuite run to see if it has any regressions
> > in comparison to my patch.  I'll report back in an hour or so.
> 
> No regressions!

Thanks for testing it!  Jim?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb.base/scope.exp problems and possible fix

[Andrew Cagney]

Jim,

> On Tue, Mar 25, 2003 at 05:29:29PM +0100, Corinna Vinschen wrote:
> 
>> But is that workaround a valid fix?
> 
> 
> I don't think it's completely right, but I have good news for you - I
> do have a patch that I think _is_ right.  I submitted it for review two
> weeks ago.  Would you please try the patch in:
>   http://sources.redhat.com/ml/gdb-patches/2003-03/msg00286.html
> and tell me whether it works as well for you?

Can you please look at this.  It's been identified as a serious problem:
http://sources.redhat.com/ml/gdb/2003-03/msg00193.html

Andrew