From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2652 invoked by alias); 4 May 2002 00:10:24 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2644 invoked from network); 4 May 2002 00:10:23 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 4 May 2002 00:10:23 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 1F2075EA11; Fri, 3 May 2002 19:10:21 -0500 (EST) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Check for corruption of cv_type chain References: <20020503215423.B21045EA11@zwingli.cygnus.com> <20020503221418.GA29293@nevyn.them.org> From: Jim Blandy Date: Fri, 03 May 2002 17:10:00 -0000 In-Reply-To: <20020503221418.GA29293@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-05/txt/msg00086.txt.bz2 Daniel Jacobowitz 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.