Re: RFA: Check for corruption of cv_type chain

[Daniel Jacobowitz <drow@mvista.com>]

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