Re: RFA: Check for corruption of cv_type chain

[Jim Blandy <jimb@redhat.com>]

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.