1# Copyright 2002-2020 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 17if { [skip_cplus_tests] } { continue } 18 19standard_testfile hang1.cc hang2.cc hang3.cc 20 21if {[prepare_for_testing "failed to prepare" $testfile \ 22 [list $srcfile $srcfile2 $srcfile3] {debug c++}]} { 23 return -1 24} 25 26# As of May 1, 2002, GDB hangs trying to read the debug info for the 27# `hang2.o' compilation unit from the executable `hang', when compiled 28# by g++ 2.96 with STABS debugging info. Here's what's going on, as 29# best as I can tell. 30# 31# The definition of `struct A' in `hang.H' refers to `struct B' as an 32# incomplete type. The stabs declare type number (1,3) to be a cross- 33# reference type, `xsB:'. 34# 35# The definition of `struct C' contains a nested definition for 36# `struct B' --- or more properly, `struct C::B'. However, the stabs 37# fail to qualify the structure tag: it just looks like a definition 38# for `struct B'. I think this is a compiler bug, but perhaps GCC 39# doesn't emit qualified names for a reason. 40# 41# `hang.H' gets #included by both `hang1.C' and `hang2.C'. So the 42# stabs for `struct A', the incomplete `struct B', and `struct C' 43# appear in both hang1.o's and hang2.o's stabs. 44# 45# When those two files are linked together, since hang2.o appears 46# later in the command line, its #inclusion of `hang.H' gets replaced 47# with an N_EXCL stab, referring back to hang1.o's stabs for the 48# header file. 49# 50# When GDB builds psymtabs for the executable hang, it notes that 51# hang2.o's stabs contain an N_EXCL referring to a header that appears 52# in full in hang1.o's stabs. So hang2.o's psymtab lists a dependency 53# on hang1.o's psymtab. 54# 55# When the user types the command `print var_in_b', GDB scans the 56# psymtabs for a symbol by that name, and decides to read full symbols 57# for `hang2.o'. 58# 59# Since `hang2.o''s psymtab lists `hang1.o' as a dependency, GDB first 60# reads `hang1.o''s symbols. When GDB sees `(1,3)=xsB:', it creates a 61# type object for `struct B', sets its TYPE_STUB flag, and records it 62# as type number `(1,3)'. 63# 64# When GDB finds the definition of `struct C::B', since the stabs 65# don't indicate that the type is nested within C, it treats it as 66# a definition of `struct B'. 67# 68# When GDB is finished reading `hang1.o''s symbols, it calls 69# `cleanup_undefined_types'. This function mistakes the definition of 70# `struct C::B' for a definition for `struct B', and overwrites the 71# incomplete type object for the real `struct B', using `memcpy'. Now 72# stabs type number `(1,3)' refers to this (incorrect) complete type. 73# Furthermore, the `memcpy' simply copies the original's `cv_type' 74# field to the target, giving the target a corrupt `cv_type' ring: the 75# chain does not point back to the target type. 76# 77# Having satisfied `hang2.o''s psymtab's dependencies, GDB begins to 78# read `hang2.o''s symbols. These contain the true definition for 79# `struct B', which refers to type number `(1,3)' as the type it's 80# defining. GDB looks up type `(1,3)', and finds the (incorrect) 81# complete type established by the call to `cleanup_undefined_types' 82# above. However, it doesn't notice that the type is already defined, 83# and passes it to `read_struct_type', which then writes the new 84# definition's size, field list, etc. into the type object which 85# already has those fields initialized. Adding insult to injury, 86# `read_struct_type' then calls `finish_cv_type'; since the `memcpy' 87# in `cleanup_undefined_types' corrupted the target type's `cv_type' 88# ring, `finish_cv_type' enters an infinite loop. 89 90# This checks that GDB recognizes when a structure is about to be 91# overwritten, and refuses, with a complaint. 92gdb_test "print var_in_b" " = 1729" "doesn't overwrite struct type" 93 94# This checks that cleanup_undefined_types doesn't create corrupt 95# cv_type chains. Note that var_in_hang3 does need to be declared in 96# a separate compilation unit, whose psymtab depends on hang1.o's 97# psymtab. Otherwise, GDB won't call cleanup_undefined_types (as it 98# finishes hang1.o's symbols) before it calls make_cv_type (while 99# reading hang3.o's symbols). 100# 101# The bug only happens when you compile with -gstabs+; Otherwise, GCC 102# won't include the `const' qualifier on `const_B_ptr' in `hang3.o''s 103# STABS, so GDB won't try to create a const variant of the smashed 104# struct type, and get caught by the corrupted cv_type chain. 105gdb_test "print var_in_hang3" " = 42" "doesn't corrupt cv_type chain" 106