This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: Check for corruption of cv_type chain
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