This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RFA: test for GDB C++ STABS problem



This one was fun!  Fix on the way.  The test contains an explanation
of the problem.

gdb/testsuite/ChangeLog:

2002-05-01  Jim Blandy  <jimb@redhat.com>

	* gdb.c++/hang1.C, gdb.c++/hang2.C, gdb.c++/hang.H,
	gdb.c++/hang.exp: New test.

Index: gdb/testsuite/gdb.c++/hang.H
===================================================================
RCS file: gdb/testsuite/gdb.c++/hang.H
diff -N gdb/testsuite/gdb.c++/hang.H
*** gdb/testsuite/gdb.c++/hang.H	1 Jan 1970 00:00:00 -0000
--- gdb/testsuite/gdb.c++/hang.H	2 May 2002 01:04:29 -0000
***************
*** 0 ****
--- 1,12 ----
+ struct A
+ {
+   struct B *b_ptr_in_a;
+ };
+ 
+ struct C
+ {
+   struct B
+   {
+     int member_of_B_in_C;
+   };
+ };
Index: gdb/testsuite/gdb.c++/hang.exp
===================================================================
RCS file: gdb/testsuite/gdb.c++/hang.exp
diff -N gdb/testsuite/gdb.c++/hang.exp
*** gdb/testsuite/gdb.c++/hang.exp	1 Jan 1970 00:00:00 -0000
--- gdb/testsuite/gdb.c++/hang.exp	2 May 2002 01:04:29 -0000
***************
*** 0 ****
--- 1,114 ----
+ #   Copyright (C) 2002 Free Software Foundation, Inc.
+ 
+ # This program is free software; you can redistribute it and/or modify
+ # it under the terms of the GNU General Public License as published by
+ # the Free Software Foundation; either version 2 of the License, or
+ # (at your option) any later version.
+ # 
+ # This program is distributed in the hope that it will be useful,
+ # but WITHOUT ANY WARRANTY; without even the implied warranty of
+ # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ # GNU General Public License for more details.
+ # 
+ # You should have received a copy of the GNU General Public License
+ # along with this program; if not, write to the Free Software
+ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+ 
+ # Please email any bugs, comments, and/or additions to this file to:
+ # bug-gdb@prep.ai.mit.edu
+ 
+ if $tracelevel then {
+ 	strace $tracelevel
+ }
+ 
+ set prms_id 0
+ set bug_id 0
+ 
+ if { [skip_cplus_tests] } { continue }
+ 
+ set testfile hang
+ set binfile ${objdir}/${subdir}/${testfile}
+ 
+ foreach file {hang1 hang2} {
+     if  { [gdb_compile "${srcdir}/${subdir}/${file}.C" "${file}.o" object {debug c++}] != "" } {
+         gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+     }
+ }
+ 
+ if {[gdb_compile "hang1.o hang2.o" ${binfile} executable {debug c++}] != "" } {
+      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+ }
+ 
+ 
+ gdb_exit
+ gdb_start
+ gdb_reinitialize_dir $srcdir/$subdir
+ gdb_load ${binfile}
+ 
+ 
+ # As of May 1, 2002, GDB hangs trying to read the debug info for the
+ # `hang2.o' compilation unit from the executable `hang', when compiled
+ # by g++ 2.96 with STABS debugging info.  Here's what's going on, as
+ # best as I can tell.
+ #
+ # The definition of `struct A' in `hang.H' refers to `struct B' as an
+ # incomplete type.  The stabs declare type number (1,3) to be a cross-
+ # reference type, `xsB:'.
+ #
+ # The definition of `struct C' contains a nested definition for
+ # `struct B' --- or more properly, `struct C::B'.  However, the stabs
+ # fail to qualify the structure tag: it just looks like a definition
+ # for `struct B'.  I think this is a compiler bug, but perhaps GCC
+ # doesn't emit qualified names for a reason.
+ #
+ # `hang.H' gets #included by both `hang1.C' and `hang2.C'.  So the
+ # stabs for `struct A', the incomplete `struct B', and `struct C'
+ # appear in both hang1.o's and hang2.o's stabs.
+ #
+ # When those two files are linked together, since hang2.o appears
+ # later in the command line, its #inclusion of `hang.H' gets replaced
+ # with an N_EXCL stab, referring back to hang1.o's stabs for the
+ # header file.
+ #
+ # When GDB builds psymtabs for the executable hang, it notes that
+ # hang2.o's stabs contain an N_EXCL referring to a header that appears
+ # in full in hang1.o's stabs.  So hang2.o's psymtab lists a dependency
+ # on hang1.o's psymtab.
+ #
+ # When the user types the command `print var_in_b', GDB scans the
+ # psymtabs for a symbol by that name, and decides to read full symbols
+ # for `hang2.o'.
+ #
+ # Since `hang2.o''s psymtab lists `hang1.o' as a dependency, GDB first
+ # reads `hang1.o''s symbols.  When GDB sees `(1,3)=xsB:', it creates a
+ # type object for `struct B', sets its TYPE_FLAG_STUB flag, and
+ # records it as type number `(1,3)'.
+ #
+ # When GDB finds the definition of `struct C::B', since the stabs
+ # don't indicate that the type is nested within C, it treats it as
+ # a definition of `struct B'.
+ #
+ # When GDB is finished reading `hang1.o''s symbols, it calls
+ # `cleanup_undefined_types'.  This function mistakes the definition of
+ # `struct C::B' for a definition for `struct B', and overwrites the
+ # incomplete type object for the real `struct B', using `memcpy'.  Now
+ # stabs type number `(1,3)' refers to this (incorrect) complete type.
+ # Furthermore, the `memcpy' simply copies the original's `cv_type'
+ # field to the target, giving the target a corrupt `cv_type' ring: the
+ # chain does not point back to the target type.
+ #
+ # Having satisfied `hang2.o''s psymtab's dependencies, GDB begins to
+ # read `hang2.o''s symbols.  These contain the true definition for
+ # `struct B', which refers to type number `(1,3)' as the type it's
+ # defining.  GDB looks up type `(1,3)', and finds the complete type
+ # established by the call to `cleanup_undefined_types' above.
+ # However, it doesn't notice that the type is already defined, and
+ # passes it to `read_struct_type', which then writes the new
+ # definition's size, field list, etc. into the type object which
+ # already has those fields initialized.  Adding insult to injury,
+ # `read_struct_type' then calls `finish_cv_type'; since the `memcpy'
+ # in `cleanup_undefined_types' corrupted the target type's `cv_type'
+ # ring, `finish_cv_type' enters an infinite loop.
+ 
+ set timeout 10
+ gdb_test "print var_in_b" " = 0" "can read debug info"
Index: gdb/testsuite/gdb.c++/hang1.C
===================================================================
RCS file: gdb/testsuite/gdb.c++/hang1.C
diff -N gdb/testsuite/gdb.c++/hang1.C
*** gdb/testsuite/gdb.c++/hang1.C	1 Jan 1970 00:00:00 -0000
--- gdb/testsuite/gdb.c++/hang1.C	2 May 2002 01:04:29 -0000
***************
*** 0 ****
--- 1,3 ----
+ #include "hang.H"
+ 
+ int main (int argc, char **argv) { return 0; }
Index: gdb/testsuite/gdb.c++/hang2.C
===================================================================
RCS file: gdb/testsuite/gdb.c++/hang2.C
diff -N gdb/testsuite/gdb.c++/hang2.C
*** gdb/testsuite/gdb.c++/hang2.C	1 Jan 1970 00:00:00 -0000
--- gdb/testsuite/gdb.c++/hang2.C	2 May 2002 01:04:29 -0000
***************
*** 0 ****
--- 1,8 ----
+ #include "hang.H"
+ 
+ struct B
+ {
+   int member_of_B;
+ };
+ 
+ int var_in_b;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]