From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8171 invoked by alias); 4 May 2002 00:25:16 -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 8125 invoked from network); 4 May 2002 00:25:12 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 4 May 2002 00:25:12 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 173nMK-0001K2-00; Fri, 03 May 2002 20:25:08 -0400 Date: Fri, 03 May 2002 17:25:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Check for corruption of cv_type chain Message-ID: <20020504002507.GA4915@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com References: <20020503215423.B21045EA11@zwingli.cygnus.com> <20020503221418.GA29293@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00088.txt.bz2 On Fri, May 03, 2002 at 07:10:21PM -0500, Jim Blandy wrote: > > 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.) 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