gdb/testsuite/gdb.cp/hang.exp

   1 #   Copyright 2002, 2004, 2007, 2008 Free Software Foundation, Inc.
   2
   3 # This program is free software; you can redistribute it and/or modify
   4 # it under the terms of the GNU General Public License as published by
   5 # the Free Software Foundation; either version 3 of the License, or
   6 # (at your option) any later version.
   7 #
   8 # This program is distributed in the hope that it will be useful,
   9 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  10 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  11 # GNU General Public License for more details.
  12 #
  13 # You should have received a copy of the GNU General Public License
  14 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
  15
  16 if $tracelevel then {
  17         strace $tracelevel
  18 }
  19
  20 set prms_id 0
  21 set bug_id 0
  22
  23 if { [skip_cplus_tests] } { continue }
  24
  25 set testfile hang
  26 set binfile ${objdir}/${subdir}/${testfile}
  27
  28 foreach file {hang1 hang2 hang3} {
  29     if {[gdb_compile "${srcdir}/${subdir}/${file}.cc" "${file}.o" object {c++ debug}] != ""} {
  30         untested hang.exp
  31         return -1
  32     }
  33 }
  34
  35 if {[gdb_compile "hang1.o hang2.o hang3.o" ${binfile} executable {c++ debug}] != "" } {
  36      untested hang.exp
  37      return -1
  38 }
  39
  40
  41 gdb_exit
  42 gdb_start
  43 gdb_reinitialize_dir $srcdir/$subdir
  44 gdb_load ${binfile}
  45
  46
  47 # As of May 1, 2002, GDB hangs trying to read the debug info for the
  48 # `hang2.o' compilation unit from the executable `hang', when compiled
  49 # by g++ 2.96 with STABS debugging info.  Here's what's going on, as
  50 # best as I can tell.
  51 #
  52 # The definition of `struct A' in `hang.H' refers to `struct B' as an
  53 # incomplete type.  The stabs declare type number (1,3) to be a cross-
  54 # reference type, `xsB:'.
  55 #
  56 # The definition of `struct C' contains a nested definition for
  57 # `struct B' --- or more properly, `struct C::B'.  However, the stabs
  58 # fail to qualify the structure tag: it just looks like a definition
  59 # for `struct B'.  I think this is a compiler bug, but perhaps GCC
  60 # doesn't emit qualified names for a reason.
  61 #
  62 # `hang.H' gets #included by both `hang1.C' and `hang2.C'.  So the
  63 # stabs for `struct A', the incomplete `struct B', and `struct C'
  64 # appear in both hang1.o's and hang2.o's stabs.
  65 #
  66 # When those two files are linked together, since hang2.o appears
  67 # later in the command line, its #inclusion of `hang.H' gets replaced
  68 # with an N_EXCL stab, referring back to hang1.o's stabs for the
  69 # header file.
  70 #
  71 # When GDB builds psymtabs for the executable hang, it notes that
  72 # hang2.o's stabs contain an N_EXCL referring to a header that appears
  73 # in full in hang1.o's stabs.  So hang2.o's psymtab lists a dependency
  74 # on hang1.o's psymtab.
  75 #
  76 # When the user types the command `print var_in_b', GDB scans the
  77 # psymtabs for a symbol by that name, and decides to read full symbols
  78 # for `hang2.o'.
  79 #
  80 # Since `hang2.o''s psymtab lists `hang1.o' as a dependency, GDB first
  81 # reads `hang1.o''s symbols.  When GDB sees `(1,3)=xsB:', it creates a
  82 # type object for `struct B', sets its TYPE_FLAG_STUB flag, and
  83 # records it as type number `(1,3)'.
  84 #
  85 # When GDB finds the definition of `struct C::B', since the stabs
  86 # don't indicate that the type is nested within C, it treats it as
  87 # a definition of `struct B'.
  88 #
  89 # When GDB is finished reading `hang1.o''s symbols, it calls
  90 # `cleanup_undefined_types'.  This function mistakes the definition of
  91 # `struct C::B' for a definition for `struct B', and overwrites the
  92 # incomplete type object for the real `struct B', using `memcpy'.  Now
  93 # stabs type number `(1,3)' refers to this (incorrect) complete type.
  94 # Furthermore, the `memcpy' simply copies the original's `cv_type'
  95 # field to the target, giving the target a corrupt `cv_type' ring: the
  96 # chain does not point back to the target type.
  97 #
  98 # Having satisfied `hang2.o''s psymtab's dependencies, GDB begins to
  99 # read `hang2.o''s symbols.  These contain the true definition for
 100 # `struct B', which refers to type number `(1,3)' as the type it's
 101 # defining.  GDB looks up type `(1,3)', and finds the (incorrect)
 102 # complete type established by the call to `cleanup_undefined_types'
 103 # above.  However, it doesn't notice that the type is already defined,
 104 # and passes it to `read_struct_type', which then writes the new
 105 # definition's size, field list, etc. into the type object which
 106 # already has those fields initialized.  Adding insult to injury,
 107 # `read_struct_type' then calls `finish_cv_type'; since the `memcpy'
 108 # in `cleanup_undefined_types' corrupted the target type's `cv_type'
 109 # ring, `finish_cv_type' enters an infinite loop.
 110
 111 # This checks that GDB recognizes when a structure is about to be
 112 # overwritten, and refuses, with a complaint.
 113 gdb_test "print var_in_b" " = 1729" "doesn't overwrite struct type"
 114
 115 # This checks that cleanup_undefined_types doesn't create corrupt
 116 # cv_type chains.  Note that var_in_hang3 does need to be declared in
 117 # a separate compilation unit, whose psymtab depends on hang1.o's
 118 # psymtab.  Otherwise, GDB won't call cleanup_undefined_types (as it
 119 # finishes hang1.o's symbols) before it calls make_cv_type (while
 120 # reading hang3.o's symbols).
 121 #
 122 # The bug only happens when you compile with -gstabs+; Otherwise, GCC
 123 # won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s
 124 # STABS, so GDB won't try to create a const variant of the smashed
 125 # struct type, and get caught by the corrupted cv_type chain.
 126 gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain"