Re: RFA: Check for corruption of cv_type chain

Re: RFA: Check for corruption of cv_type chain

[Michael Elizabeth Chastain]

! # These tests are intended to catch problems in the STABS reader, so I
! # think it's okay to override the preference the user expressed in
! # their $DEJAGNU file or whatever, and explicitly request extended
! # stabs debugging information.  But, if we don't know how to do that,
! # these tests still should pass just fine if the executable uses some
! # other format.

As Daniel J said, please don't do that.

This makes life harder for me.  I'd like the tests to be agnostic about
the configurations, and then have the test bed software iterate over
all the interesting configurations.

Suppose that a similar bug started happening with -gdwarf-3, or with a
coff version of gcc (such as Cygwin's gcc), or with the native Solaris
or Irix or HP-UX C++ compiler?

Michael C

Re: RFA: Check for corruption of cv_type chain

[Jim Blandy]

Second try.

2002-05-03  Jim Blandy  <jimb@redhat.com>

	* gdb.c++/hang.exp: Check for corruption of the cv_type chain.
	* gdb.c++/hang3.C: New file.

Index: gdb/testsuite/gdb.c++/hang.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/hang.exp,v
retrieving revision 1.1
diff -c -r1.1 hang.exp
*** gdb/testsuite/gdb.c++/hang.exp	2 May 2002 07:03:53 -0000	1.1
--- gdb/testsuite/gdb.c++/hang.exp	4 May 2002 00:27:05 -0000
***************
*** 29,41 ****
  set testfile hang
  set binfile ${objdir}/${subdir}/${testfile}
  
! foreach file {hang1 hang2} {
!     if  { [gdb_compile "${srcdir}/${subdir}/${file}.C" "${file}.o" object {debug c++}] != "" } {
          gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
      }
  }
  
! if {[gdb_compile "hang1.o hang2.o" ${binfile} executable {debug c++}] != "" } {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  
--- 29,41 ----
  set testfile hang
  set binfile ${objdir}/${subdir}/${testfile}
  
! foreach file {hang1 hang2 hang3} {
!     if {[gdb_compile "${srcdir}/${subdir}/${file}.C" "${file}.o" object {c++ debug}] != ""} {
          gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
      }
  }
  
! if {[gdb_compile "hang1.o hang2.o hang3.o" ${binfile} executable {c++ debug}] != "" } {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  
***************
*** 110,113 ****
  # in `cleanup_undefined_types' corrupted the target type's `cv_type'
  # ring, `finish_cv_type' enters an infinite loop.
  
! gdb_test "print var_in_b" " = 1729" "can read debug info"
--- 110,128 ----
  # in `cleanup_undefined_types' corrupted the target type's `cv_type'
  # ring, `finish_cv_type' enters an infinite loop.
  
! # This checks that GDB recognizes when a structure is about to be
! # overwritten, and refuses, with a complaint.
! gdb_test "print var_in_b" " = 1729" "doesn't overwrite struct type"
! 
! # This checks that cleanup_undefined_types doesn't create corrupt
! # cv_type chains.  Note that var_in_hang3 does need to be declared in
! # a separate compilation unit, whose psymtab depends on hang1.o's
! # psymtab.  Otherwise, GDB won't call cleanup_undefined_types (as it
! # finishes hang1.o's symbols) before it calls make_cv_type (while
! # reading hang3.o's symbols).
! #
! # The bug only happens when you compile with -gstabs+; Otherwise, GCC
! # won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s
! # STABS, so GDB won't try to create a const variant of the smashed
! # struct type, and get caught by the corrupted cv_type chain.
! gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain"
Index: gdb/testsuite/gdb.c++/hang3.C
===================================================================
RCS file: gdb/testsuite/gdb.c++/hang3.C
diff -N gdb/testsuite/gdb.c++/hang3.C
*** gdb/testsuite/gdb.c++/hang3.C	1 Jan 1970 00:00:00 -0000
--- gdb/testsuite/gdb.c++/hang3.C	4 May 2002 00:27:05 -0000
***************
*** 0 ****
--- 1,4 ----
+ #include "hang.H"
+ 
+ const struct B *const_B_ptr;
+ int var_in_hang3 = 42;

Re: RFA: Check for corruption of cv_type chain

[Michael Elizabeth Chastain]

Jim Blandy writes:
> [goes and checks his compilers] I see what's going on now.  In GCC
> 2.96, -g doesn't get you `const' and `volatile' qualifiers in stabs
> --- that's why I thought -gstabs was the default.  But in fact, GCC
> 2.96 won't give you those qualifiers no matter how nicely you ask.

Yes, you can see that happening here:

  http://www.shout.net/~mec/sunday/2002-05-01/Attention-gdb-HEAD.html

Look at the lines for gdb.base/constvars.exp and gdb.base/volatile.exp.
gcc 2.95.3 -gstabs+ and gcc 2.96 -gstabs+ give many XFAIL's for these
tests.

> The current GCC sources default to Dwarf 2.  So except for the
> window between the point where we taught dbxout.c to emit the
> qualifiers, and the point where we made Dwarf 2 the default (a pretty
> narrow window, in terms of installed base, no?), it doesn't matter
> whether -gstabs+ is the default or not; this test won't do its job
> with the default flags.

Two comments.  First, gcc 3.0.4 falls into that window, and it is
the current released compiler.  Indeed, every other gcc released in
the past twelve months or so has been a gcc 3.0.X compiler, so it
will have the cv qualifiers and have -gstabs+ as default.  The window
is not narrow at all.

Second, the new tests are FAILing with gcc 2.95.3 -gstabs+ and
gcc 2.96-rh -gstabs+, the same way they fail with gcc 3.0.4 -gstabs+
and the other gcc 3-series compilers.

Let me pop open the logs:

  # gcc 2.95.3 -gstabs+
  (gdb) print var_in_b^M
  FAIL: gdb.c++/hang.exp: doesn't overwrite struct type (timeout)
  print var_in_hang3^M
  FAIL: gdb.c++/hang.exp: doesn't corrupt cv_type chain (timeout)
  testcase /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.c++/hang.exp
  completed in 125 seconds

  # gcc 2.96.3 -gstabs+
  (gdb) file /berman/fsf/_today_/berman/test/gdb.c++/hang^M
  Reading symbols from /berman/fsf/_today_/berman/test/gdb.c++/hang...done.^M
  (gdb) print var_in_b^M
  FAIL: gdb.c++/hang.exp: doesn't overwrite struct type (timeout)
  print var_in_hang3^M
  FAIL: gdb.c++/hang.exp: doesn't corrupt cv_type chain (timeout)
  testcase /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.c++/hang.exp
  completed in 126 seconds

The logs, executable files, and so on, are in the tarballs that I posted.

Michael C

Re: RFA: Check for corruption of cv_type chain

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Fri, May 03, 2002 at 07:10:21PM -0500, Jim Blandy wrote:
> > 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > On Fri, May 03, 2002 at 04:54:23PM -0500, Jim Blandy wrote:
> > > 
> > > > ! # These tests are intended to catch problems in the STABS reader, so I
> > > > ! # think it's okay to override the preference the user expressed in
> > > > ! # their $DEJAGNU file or whatever, and explicitly request extended
> > > > ! # stabs debugging information.  But, if we don't know how to do that,
> > > > ! # these tests still should pass just fine if the executable uses some
> > > > ! # other format.
> > > > ! #
> > > > ! # Plain old -gstabs isn't enough, by the way.  See the notes for
> > > > ! # "doesn't corrupt cv_type chain", below.
> > > > ! if {$gcc_compiled} {
> > > > !     set debug_option additional_flags=-gstabs+
> > > > ! } else {
> > > > !     set debug_option debug
> > > > ! }
> > > > ! set options [list c++ $debug_option]
> > > 
> > > Please don't... -gstabs+ is a configuration; if we test that
> > > configuration, which is the default pre-3.1, then we will see the bug. 
> > > If I run a DWARF-2 testsuite explicitly I don't really want to look at
> > > bugs in the stabs reader.
> > 
> > It doesn't seem to the default pre-3.1.  -gstabs is.  (I think.)
> 
> No, -gstabs+ is definitely the default.  Our C++ debugging with -gstabs
> is practically nil, so we'd notice :)

[goes and checks his compilers] I see what's going on now.  In GCC
2.96, -g doesn't get you `const' and `volatile' qualifiers in stabs
--- that's why I thought -gstabs was the default.  But in fact, GCC
2.96 won't give you those qualifiers no matter how nicely you ask.

The current GCC sources default to Dwarf 2.  So except for the
window between the point where we taught dbxout.c to emit the
qualifiers, and the point where we made Dwarf 2 the default (a pretty
narrow window, in terms of installed base, no?), it doesn't matter
whether -gstabs+ is the default or not; this test won't do its job
with the default flags.

Oh well.  If someone is explicitly interested in -gstabs+, they should
run the test suite with that flag, and then the test will do its job.
I guess I shouldn't worry about it any more.

Re: RFA: Check for corruption of cv_type chain

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> Er... fails on 3.0.4 DWARF-2?  Does anyone know why?

I threw up some tarballs (errr ...)

  ftp://ftp.shout.net/pub/users/mec/gdb/2002-05-01c,result.tar.gz
  ftp://ftp.shout.net/pub/users/mec/gdb/2002-05-01c,testsuite.tar.gz

result.tar.gz has ten subdirectories, one per each configuration.
You want the one with gcc-3.0.4,g-dwarf-2 in the name.  There is a nice
gdb.log and executable file "gdb.c++/hang".

testsuite.tar.gz has the source for the testsuite.  The GPL requires me
to make this available because result.tar.gz has test binaries in it.
Plus, you can see exactly what went into my "gdb.c++/hang" binary if
you need to.

The gdb.log for gcc 3.0.4 -gdwarf-2 says:

  (gdb) print var_in_b^M
  ERROR: Process no longer exists
  UNRESOLVED: gdb.c++/hang.exp: doesn't overwrite struct type
  FAIL: gdb.c++/hang.exp: doesn't corrupt cv_type chain (timeout)
  testcase /berman/fsf/_today_/source/gdb/HEAD/src/gdb/testsuite/gdb.c++/hang.exp
  completed in 62 seconds

gdb dumped core.  Here is a typescript with the backtrace.

Michael C

===

Script started on Fri May  3 22:29:57 2002
[mec@berman 2002-05-01c,native,i686-pc-linux-gnu%rh-7.2,HEAD,3.0.4,g-dwarf-2]$ g db /berman/fsf/_today_/berman/native/install/gdb/HEAD/bin/gdb core
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/berman/fsf/_today_/berman/native/install/gdb/HEAD/bin/gdb -nw -nx'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libthread_db.so.1...done.
Loaded symbols for /lib/libthread_db.so.1
#0  dwarf_decode_lines (offset=185, comp_dir=0x0, abfd=0x8409c10, 
    cu_header=0xbfffe000)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2read.c:4070
4070	  lh.standard_opcode_lengths[0] = 1;
(gdb) set height 0
(gdb) backtrace
#0  dwarf_decode_lines (offset=185, comp_dir=0x0, abfd=0x8409c10, 
    cu_header=0xbfffe000)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2read.c:4070
#1  0x0812b80c in read_file_scope (die=0x8417668, objfile=0x841ff90, 
    cu_header=0xbfffe000)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2read.c:1678
#2  0x0812b37c in psymtab_to_symtab_1 (pst=0x842bd84)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2read.c:1449
#3  0x0812b232 in dwarf2_psymtab_to_symtab (pst=0x842bd84)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/dwarf2read.c:1396
#4  0x080a5f89 in psymtab_to_symtab (pst=0x842bd84)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/symfile.c:374
#5  0x080a17c9 in lookup_symbol_aux (name=0xbffff040 "var_in_b", 
    mangled_name=0x0, block=0x0, namespace=VAR_NAMESPACE, 
    is_a_field_of_this=0xbfffe170, symtab=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/symtab.c:923
#6  0x080a13b4 in lookup_symbol (name=0xbffff040 "var_in_b", block=0x0, 
    namespace=VAR_NAMESPACE, is_a_field_of_this=0xbfffe170, symtab=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/symtab.c:716
#7  0x08119a93 in c_lex ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/c-exp.y:1622
#8  0x08119275 in c_parse ()
    at /berman/migchain/install/native/bison-1.35/share/bison/bison.simple:573
#9  0x080dc2c1 in parse_exp_1 (stringptr=0xbffff080, block=0x0, comma=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/parse.c:1153
#10 0x080dc3b5 in parse_expression (string=0x83d996e "var_in_b")
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/parse.c:1191
#11 0x0809e0d9 in print_command_1 (exp=0x83d996e "var_in_b", inspect=0, 
    voidprint=1) at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/printcmd.c:922
#12 0x0809e2f3 in print_command (exp=0x83d996e "var_in_b", from_tty=1)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/printcmd.c:988
#13 0x081538c4 in do_cfunc (c=0x83e18b0, args=0x83d996e "var_in_b", from_tty=1)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/cli/cli-decode.c:52
#14 0x080f3093 in execute_command (p=0x83d9975 "b", from_tty=1)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:711
#15 0x080b9a2d in command_handler (command=0x83d9968 "print var_in_b")
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:504
#16 0x080b9ef3 in command_line_handler (rl=0x83edd80 "print var_in_b")
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:797
#17 0x081b9dd6 in rl_callback_read_char ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/readline/callback.c:114
#18 0x080b93bb in rl_callback_read_char_wrapper (client_data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:168
#19 0x080b991f in stdin_event_handler (error=0, client_data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-top.c:418
#20 0x081075e7 in handle_file_event (event_file_desc=0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:714
#21 0x0810705e in process_event ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:335
#22 0x081070ab in gdb_do_one_event (data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:372
#23 0x080f2d1f in do_catch_errors (uiout=0x83f7908, data=0xbffff380)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:492
#24 0x080f2c61 in catcher (func=0x80f2d10 <do_catch_errors>, 
    func_uiout=0x83f7908, func_args=0xbffff380, func_val=0xbffff378, 
    func_caught=0xbffff37c, errstring=0x832bda0 "", mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:424
#25 0x080f2d66 in catch_errors (func=0x8107080 <gdb_do_one_event>, 
    func_args=0x0, errstring=0x832bda0 "", mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:504
#26 0x081070e3 in start_event_loop ()
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/event-loop.c:396
#27 0x0808ad41 in captured_command_loop (data=0x0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:94
#28 0x080f2d1f in do_catch_errors (uiout=0x83f7908, data=0xbffff4f0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:492
#29 0x080f2c61 in catcher (func=0x80f2d10 <do_catch_errors>, 
    func_uiout=0x83f7908, func_args=0xbffff4f0, func_val=0xbffff4e8, 
    func_caught=0xbffff4ec, errstring=0x82fc51e "", mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:424
#30 0x080f2d66 in catch_errors (func=0x808ad30 <captured_command_loop>, 
    func_args=0x0, errstring=0x82fc51e "", mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:504
#31 0x0808b313 in captured_main (data=0xbffff7b0)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:723
#32 0x080f2d1f in do_catch_errors (uiout=0x838e3e0, data=0xbffff790)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:492
#33 0x080f2c61 in catcher (func=0x80f2d10 <do_catch_errors>, 
    func_uiout=0x838e3e0, func_args=0xbffff790, func_val=0xbffff788, 
    func_caught=0xbffff78c, errstring=0x82fc51e "", mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:424
#34 0x080f2d66 in catch_errors (func=0x808ad80 <captured_main>, 
    func_args=0xbffff7b0, errstring=0x82fc51e "", mask=6)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/top.c:504
#35 0x0808b89a in main (argc=3, argv=0xbffff824)
    at /berman/fsf/_today_/source/gdb/HEAD/src/gdb/main.c:734
#36 0x4018e507 in __libc_start_main (main=0x808b870 <main>, argc=3, 
    ubp_av=0xbffff824, init=0x8089430 <_init>, fini=0x82fc3b0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff81c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) quit
[mec@berman 2002-05-01c,native,i686-pc-linux-gnu%rh-7.2,HEAD,3.0.4,g-dwarf-2]$ e xit
Script done on Fri May  3 22:30:33 2002

Re: RFA: Check for corruption of cv_type chain

[Michael Elizabeth Chastain]

Michael Snyder writes:
> We're supposed to be trying to _reduce_ the number of "ignore" failures.
> Can't we xfail this on targets that don't support stabs or something?

I think there's a misunderstanding here.  As I've posted, all Jim's
tests PASS on all my -gdwarf-2 configurations, except for gcc 3.0.4.

And the gcc 3.0.4 -gdwarf-2 configuration is definitely not an "ignore"
failure, it's gdb crashing.  I'll put the files up for ftp so that
Daniel J can have a look at it.

Michael C

Re: RFA: Check for corruption of cv_type chain

[Daniel Jacobowitz]

On Fri, May 03, 2002 at 07:54:38PM -0500, Michael Elizabeth Chastain wrote:
> This patch is approved.
> 
> The new test behaves like the others:
> 
>   PASS
>     gcc 2.95.3 -gdwarf-2
>     gcc 2.96-rh -gdwarf-2
>     gcc gcc-3_1-branch -gdwarf-2
>     gcc HEAD -gdwarf-2
> 
>   FAIL
>     gcc 2.95.3 -gstabs+
>     gcc 2.96-rh -gstabs+
>     gcc 3.0.4 -gdwarf-2

Er... fails on 3.0.4 DWARF-2?  Does anyone know why?

>     gcc 3.0.4 -gstabs+
>     gcc gcc-3_1-branch -gstabs+
>     gcc HEAD -gstabs+
> 
> Thanks,
> 
> Michael C
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Check for corruption of cv_type chain

[Michael Snyder]

Jim Blandy wrote:

> If you're testing the Dwarf 2 support, you have to ignore all sorts of
> failures; why is this one any different?  

NNNNNOOOOOOOOooooooooooo!!!
We're supposed to be trying to _reduce_ the number of "ignore" failures.
Can't we xfail this on targets that don't support stabs or something?

BTW, Jim, that would include all 64-bit targets...

Re: RFA: Check for corruption of cv_type chain

[Michael Elizabeth Chastain]

This patch is approved.

The new test behaves like the others:

  PASS
    gcc 2.95.3 -gdwarf-2
    gcc 2.96-rh -gdwarf-2
    gcc gcc-3_1-branch -gdwarf-2
    gcc HEAD -gdwarf-2

  FAIL
    gcc 2.95.3 -gstabs+
    gcc 2.96-rh -gstabs+
    gcc 3.0.4 -gdwarf-2
    gcc 3.0.4 -gstabs+
    gcc gcc-3_1-branch -gstabs+
    gcc HEAD -gstabs+

Thanks,

Michael C

Re: RFA: Check for corruption of cv_type chain

[Michael Elizabeth Chastain]

Jim Blandy writes:

> It doesn't seem to the default pre-3.1.  -gstabs is.  (I think.)

On native i686-pc-linux-gnu, with gcc 3.0.4 in a usual configuration,
"gcc -g" emits stabs+ format, not stabs format.  This is also true for
gcc 2.95.3.

I just checked this with some trial programs, plus I run the test suite
every so often with a lot of different "-g" options, including -g,
-gstabs, -gstabs+, -gdwarf, and -gdwarf-2.

> Given that it's not the default, I guess I'm worried that this test
> won't behave properly as a regression test, because people so rarely
> run the test in that configuration.

You don't have to worry about this, because "-g" maps to "-gstabs+"
rather than "-gstabs".

(Actually you and I probably still have a philosophical difference here.
I would argue for keeping the test agnostic *even if* "-g" mapped to
"-gstabs".  But with the facts as they are, I think that difference
between us can be moot.)

Michael C

Re: RFA: Check for corruption of cv_type chain

[Daniel Jacobowitz]

On Fri, May 03, 2002 at 07:10:21PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Fri, May 03, 2002 at 04:54:23PM -0500, Jim Blandy wrote:
> > 
> > > ! # These tests are intended to catch problems in the STABS reader, so I
> > > ! # think it's okay to override the preference the user expressed in
> > > ! # their $DEJAGNU file or whatever, and explicitly request extended
> > > ! # stabs debugging information.  But, if we don't know how to do that,
> > > ! # these tests still should pass just fine if the executable uses some
> > > ! # other format.
> > > ! #
> > > ! # Plain old -gstabs isn't enough, by the way.  See the notes for
> > > ! # "doesn't corrupt cv_type chain", below.
> > > ! if {$gcc_compiled} {
> > > !     set debug_option additional_flags=-gstabs+
> > > ! } else {
> > > !     set debug_option debug
> > > ! }
> > > ! set options [list c++ $debug_option]
> > 
> > Please don't... -gstabs+ is a configuration; if we test that
> > configuration, which is the default pre-3.1, then we will see the bug. 
> > If I run a DWARF-2 testsuite explicitly I don't really want to look at
> > bugs in the stabs reader.
> 
> It doesn't seem to the default pre-3.1.  -gstabs is.  (I think.)

No, -gstabs+ is definitely the default.  Our C++ debugging with -gstabs
is practically nil, so we'd notice :)

> Given that it's not the default, I guess I'm worried that this test
> won't behave properly as a regression test, because people so rarely
> run the test in that configuration.
> 
> If you're testing the Dwarf 2 support, you have to ignore all sorts of
> failures; why is this one any different?  It won't appear or disappear
> when you change your config, so it shouldn't show up in test summary
> diffs.
> 
> I don't object to what you're saying; I just want to have the
> regression test be effective.

I don't ignore any failures when testing DWARF-2, actually.  I don't
look just at testrun diffs; pretty much all FAILs on my normal
platforms are legitimate now.

> > > ! # This checks that cleanup_undefined_types doesn't create corrupt
> > > ! # cv_type chains.  Note that var_in_hang3 does need to be declared in
> > > ! # a separate compilation unit, whose psymtab depends on hang1.o's
> > > ! # psymtab.  Otherwise, GDB won't call cleanup_undefined_types (as it
> > > ! # finishes hang1.o's symbols) before it calls make_cv_type (while
> > > ! # reading hang3.o's symbols).
> > > ! #
> > > ! # The bug only happens when you compile with -gstabs+; Otherwise, GCC
> > > ! # won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s
> > > ! # STABS, so GDB won't try to create a const variant of the smashed
> > > ! # struct type, and get caught by the corrupted cv_type chain.
> > > ! gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain"
> > 
> > Is this the same as gdb/521?
> 
> Yes, that looks like exactly this problem.

Interesting...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: Check for corruption of cv_type chain

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> On Fri, May 03, 2002 at 04:54:23PM -0500, Jim Blandy wrote:
> 
> > ! # These tests are intended to catch problems in the STABS reader, so I
> > ! # think it's okay to override the preference the user expressed in
> > ! # their $DEJAGNU file or whatever, and explicitly request extended
> > ! # stabs debugging information.  But, if we don't know how to do that,
> > ! # these tests still should pass just fine if the executable uses some
> > ! # other format.
> > ! #
> > ! # Plain old -gstabs isn't enough, by the way.  See the notes for
> > ! # "doesn't corrupt cv_type chain", below.
> > ! if {$gcc_compiled} {
> > !     set debug_option additional_flags=-gstabs+
> > ! } else {
> > !     set debug_option debug
> > ! }
> > ! set options [list c++ $debug_option]
> 
> Please don't... -gstabs+ is a configuration; if we test that
> configuration, which is the default pre-3.1, then we will see the bug. 
> If I run a DWARF-2 testsuite explicitly I don't really want to look at
> bugs in the stabs reader.

It doesn't seem to the default pre-3.1.  -gstabs is.  (I think.)

Given that it's not the default, I guess I'm worried that this test
won't behave properly as a regression test, because people so rarely
run the test in that configuration.

If you're testing the Dwarf 2 support, you have to ignore all sorts of
failures; why is this one any different?  It won't appear or disappear
when you change your config, so it shouldn't show up in test summary
diffs.

I don't object to what you're saying; I just want to have the
regression test be effective.


> > ! # This checks that cleanup_undefined_types doesn't create corrupt
> > ! # cv_type chains.  Note that var_in_hang3 does need to be declared in
> > ! # a separate compilation unit, whose psymtab depends on hang1.o's
> > ! # psymtab.  Otherwise, GDB won't call cleanup_undefined_types (as it
> > ! # finishes hang1.o's symbols) before it calls make_cv_type (while
> > ! # reading hang3.o's symbols).
> > ! #
> > ! # The bug only happens when you compile with -gstabs+; Otherwise, GCC
> > ! # won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s
> > ! # STABS, so GDB won't try to create a const variant of the smashed
> > ! # struct type, and get caught by the corrupted cv_type chain.
> > ! gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain"
> 
> Is this the same as gdb/521?

Yes, that looks like exactly this problem.

Re: RFA: Check for corruption of cv_type chain

[Daniel Jacobowitz]

On Fri, May 03, 2002 at 04:54:23PM -0500, Jim Blandy wrote:

> ! # These tests are intended to catch problems in the STABS reader, so I
> ! # think it's okay to override the preference the user expressed in
> ! # their $DEJAGNU file or whatever, and explicitly request extended
> ! # stabs debugging information.  But, if we don't know how to do that,
> ! # these tests still should pass just fine if the executable uses some
> ! # other format.
> ! #
> ! # Plain old -gstabs isn't enough, by the way.  See the notes for
> ! # "doesn't corrupt cv_type chain", below.
> ! if {$gcc_compiled} {
> !     set debug_option additional_flags=-gstabs+
> ! } else {
> !     set debug_option debug
> ! }
> ! set options [list c++ $debug_option]

Please don't... -gstabs+ is a configuration; if we test that
configuration, which is the default pre-3.1, then we will see the bug. 
If I run a DWARF-2 testsuite explicitly I don't really want to look at
bugs in the stabs reader.

> ! # This checks that cleanup_undefined_types doesn't create corrupt
> ! # cv_type chains.  Note that var_in_hang3 does need to be declared in
> ! # a separate compilation unit, whose psymtab depends on hang1.o's
> ! # psymtab.  Otherwise, GDB won't call cleanup_undefined_types (as it
> ! # finishes hang1.o's symbols) before it calls make_cv_type (while
> ! # reading hang3.o's symbols).
> ! #
> ! # The bug only happens when you compile with -gstabs+; Otherwise, GCC
> ! # won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s
> ! # STABS, so GDB won't try to create a const variant of the smashed
> ! # struct type, and get caught by the corrupted cv_type chain.
> ! gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain"

Is this the same as gdb/521?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

RFA: Check for corruption of cv_type chain

[Jim Blandy]

This extends hang.exp to test for both of the bugs described in its
comments.

2002-05-03  Jim Blandy  <jimb@redhat.com>

	* gdb.c++/hang.exp: Check for corruption of the cv_type chain.
	If we're compiling with GCC, pass the -gstabs+ flag, to get
	the stabs needed to trigger the bug.
	* gdb.c++/hang3.C: New file.

Index: gdb/testsuite/gdb.c++/hang.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/hang.exp,v
retrieving revision 1.1
diff -c -r1.1 hang.exp
*** gdb/testsuite/gdb.c++/hang.exp	2 May 2002 07:03:53 -0000	1.1
--- gdb/testsuite/gdb.c++/hang.exp	3 May 2002 18:23:49 -0000
***************
*** 29,41 ****
  set testfile hang
  set binfile ${objdir}/${subdir}/${testfile}
  
! foreach file {hang1 hang2} {
!     if  { [gdb_compile "${srcdir}/${subdir}/${file}.C" "${file}.o" object {debug c++}] != "" } {
          gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
      }
  }
  
! if {[gdb_compile "hang1.o hang2.o" ${binfile} executable {debug c++}] != "" } {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  
--- 29,61 ----
  set testfile hang
  set binfile ${objdir}/${subdir}/${testfile}
  
! if [get_compiler_info ${binfile} "c++"] {
!     return -1;
! }
! 
! # These tests are intended to catch problems in the STABS reader, so I
! # think it's okay to override the preference the user expressed in
! # their $DEJAGNU file or whatever, and explicitly request extended
! # stabs debugging information.  But, if we don't know how to do that,
! # these tests still should pass just fine if the executable uses some
! # other format.
! #
! # Plain old -gstabs isn't enough, by the way.  See the notes for
! # "doesn't corrupt cv_type chain", below.
! if {$gcc_compiled} {
!     set debug_option additional_flags=-gstabs+
! } else {
!     set debug_option debug
! }
! set options [list c++ $debug_option]
! 
! foreach file {hang1 hang2 hang3} {
!     if  {[gdb_compile "${srcdir}/${subdir}/${file}.C" "${file}.o" object $options] != ""} {
          gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
      }
  }
  
! if {[gdb_compile "hang1.o hang2.o hang3.o" ${binfile} executable $options] != "" } {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }
  
***************
*** 110,113 ****
  # in `cleanup_undefined_types' corrupted the target type's `cv_type'
  # ring, `finish_cv_type' enters an infinite loop.
  
! gdb_test "print var_in_b" " = 1729" "can read debug info"
--- 130,148 ----
  # in `cleanup_undefined_types' corrupted the target type's `cv_type'
  # ring, `finish_cv_type' enters an infinite loop.
  
! # This checks that GDB recognizes when a structure is about to be
! # overwritten, and refuses, with a complaint.
! gdb_test "print var_in_hang2" " = 1729" "doesn't overwrite struct type"
! 
! # This checks that cleanup_undefined_types doesn't create corrupt
! # cv_type chains.  Note that var_in_hang3 does need to be declared in
! # a separate compilation unit, whose psymtab depends on hang1.o's
! # psymtab.  Otherwise, GDB won't call cleanup_undefined_types (as it
! # finishes hang1.o's symbols) before it calls make_cv_type (while
! # reading hang3.o's symbols).
! #
! # The bug only happens when you compile with -gstabs+; Otherwise, GCC
! # won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s
! # STABS, so GDB won't try to create a const variant of the smashed
! # struct type, and get caught by the corrupted cv_type chain.
! gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain"
Index: gdb/testsuite/gdb.c++/hang2.C
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/hang2.C,v
retrieving revision 1.1
diff -c -r1.1 hang2.C
*** gdb/testsuite/gdb.c++/hang2.C	2 May 2002 07:03:53 -0000	1.1
--- gdb/testsuite/gdb.c++/hang2.C	3 May 2002 18:23:49 -0000
***************
*** 5,8 ****
    int member_of_B;
  };
  
! int var_in_b = 1729;
--- 5,8 ----
    int member_of_B;
  };
  
! int var_in_hang2 = 1729;
Index: gdb/testsuite/gdb.c++/hang3.C
===================================================================
RCS file: gdb/testsuite/gdb.c++/hang3.C
diff -N gdb/testsuite/gdb.c++/hang3.C
*** gdb/testsuite/gdb.c++/hang3.C	1 Jan 1970 00:00:00 -0000
--- gdb/testsuite/gdb.c++/hang3.C	3 May 2002 18:23:49 -0000
***************
*** 0 ****
--- 1,4 ----
+ #include "hang.H"
+ 
+ const struct B *const_B_ptr;
+ int var_in_hang3 = 42;