Re: RFA: Check for corruption of cv_type chain

[Daniel Jacobowitz <drow@mvista.com>]

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