Is gdb.c++/local.exp broken?

Is gdb.c++/local.exp broken?

[Jim Blandy]

The recent change to dwarf2read.c:read_func_scope causes the following
known failure:

! FAIL: gdb.c++/local.exp: ptype Local (gdb/483)

to change to this unknown failure:

! FAIL: gdb.c++/local.exp: ptype Local

The bug in the database, gdb/483, is that the type Local gets printed
incorrectly.  But if you look at gdb/testsuite/gdb.c++/local.cc, the
type Local isn't even in scope at that point --- on line 59, after the
return of marker1.  I don't think it should be printed at all.  And in
fact, with the recent change to read_func_scope, that's what GDB does,
under Dwarf 2:

Breakpoint 2, marker1() () at /home/jimb/cygnus/src/sourceware/gdb/gdb_5_3/src/gdb/testsuite/gdb.c++/local.cc:5
5	}
(gdb) up
#1  0x08048438 in main () at /home/jimb/cygnus/src/sourceware/gdb/gdb_5_3/src/gdb/testsuite/gdb.c++/local.cc:59
59	   marker1();
(gdb) PASS: gdb.c++/local.exp: up from marker1
ptype Local
No symbol "Local" in current context.
(gdb) FAIL: gdb.c++/local.exp: ptype Local

I kind of think the test should actually try to print Local while
stopped in the function `foobar', and print InnerLocal while stopped
in main, and check that Local isn't defined.  That, however,
introduces a new failure in the STABS side, which still isn't scoping
Local correctly.

Is my understanding of this correct?  If I file a PR for the stabs
side of things, can I mark the STABS failure as a kfail, and commit
this change?

Index: gdb/testsuite/gdb.c++/local.cc
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/local.cc,v
retrieving revision 1.2
diff -c -r1.2 local.cc
*** gdb/testsuite/gdb.c++/local.cc	10 Apr 2002 03:52:21 -0000	1.2
--- gdb/testsuite/gdb.c++/local.cc	13 Nov 2002 21:09:53 -0000
***************
*** 4,9 ****
--- 4,12 ----
  { 
  }
  
+ void marker2 (void)
+ {
+ }
    
  int foobar (int x)
  {
***************
*** 20,25 ****
--- 23,30 ----
    static Local l1;
    char  c;
  
+   marker1 ();
+ 
    l.loc1 = 23;
  
    c = l.loc_foo('x');
***************
*** 56,61 ****
  
     il.ilc = 'b';
     il.ip = &c;
!    marker1();
   }
  }
--- 61,66 ----
  
     il.ilc = 'b';
     il.ip = &c;
!    marker2();
   }
  }
Index: gdb/testsuite/gdb.c++/local.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/local.exp,v
retrieving revision 1.9
diff -c -r1.9 local.exp
*** gdb/testsuite/gdb.c++/local.exp	27 May 2002 18:00:14 -0000	1.9
--- gdb/testsuite/gdb.c++/local.exp	13 Nov 2002 21:09:53 -0000
***************
*** 67,73 ****
      continue
  }
  
! gdb_test "up" ".*main.*" "up from marker1"
  
  # Local classes in g++ get names like "main.1::InnerLocal", just like local
  # static variables.  Some targets use "___" instead of ".".
--- 67,73 ----
      continue
  }
  
! gdb_test "up" ".*foobar.*" "up from marker1"
  
  # Local classes in g++ get names like "main.1::InnerLocal", just like local
  # static variables.  Some targets use "___" instead of ".".
***************
*** 110,115 ****
--- 110,127 ----
    -re ".*$gdb_prompt $"   {  fail "ptype Local" }
    timeout             { fail "(timeout) ptype Local" }
  }
+ 
+ if ![runto 'marker2'] then {
+     perror "couldn't run to marker2"
+     continue
+ }
+ 
+ gdb_test "up" ".*main.*" "up from marker2"
+ 
+ # Make sure that `Local' isn't in scope here; it's local to foobar.
+ gdb_test "ptype Local" "No symbol \"Local\" in current context.*" \
+          "Local out of scope"
+ 
  
  # DTS CLLbs14316 and CLLbs17058
  # coulter - I added a clause for HP's aCC compiler.  We print out the type

Re: Is gdb.c++/local.exp broken?

[Daniel Jacobowitz]

On Wed, Nov 13, 2002 at 03:56:42PM -0500, Jim Blandy wrote:
> 
> The recent change to dwarf2read.c:read_func_scope causes the following
> known failure:
> 
> ! FAIL: gdb.c++/local.exp: ptype Local (gdb/483)
> 
> to change to this unknown failure:
> 
> ! FAIL: gdb.c++/local.exp: ptype Local
> 
> The bug in the database, gdb/483, is that the type Local gets printed
> incorrectly.  But if you look at gdb/testsuite/gdb.c++/local.cc, the
> type Local isn't even in scope at that point --- on line 59, after the
> return of marker1.  I don't think it should be printed at all.  And in
> fact, with the recent change to read_func_scope, that's what GDB does,
> under Dwarf 2:
> 
> Breakpoint 2, marker1() () at /home/jimb/cygnus/src/sourceware/gdb/gdb_5_3/src/gdb/testsuite/gdb.c++/local.cc:5
> 5	}
> (gdb) up
> #1  0x08048438 in main () at /home/jimb/cygnus/src/sourceware/gdb/gdb_5_3/src/gdb/testsuite/gdb.c++/local.cc:59
> 59	   marker1();
> (gdb) PASS: gdb.c++/local.exp: up from marker1
> ptype Local
> No symbol "Local" in current context.
> (gdb) FAIL: gdb.c++/local.exp: ptype Local
> 
> I kind of think the test should actually try to print Local while
> stopped in the function `foobar', and print InnerLocal while stopped
> in main, and check that Local isn't defined.  That, however,
> introduces a new failure in the STABS side, which still isn't scoping
> Local correctly.
> 
> Is my understanding of this correct?  If I file a PR for the stabs
> side of things, can I mark the STABS failure as a kfail, and commit
> this change?

While I can't approve testsuite patches, I can certainly confirm your
reading of the testcase.  If our current frame is in main, there's no
reason Local should be considered to be in scope, and plenty of reason
we should make sure that it isn't.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer