mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-15 04:31:49 +08:00
4a94e36819
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
106 lines
4.9 KiB
Plaintext
106 lines
4.9 KiB
Plaintext
# Copyright 2002-2022 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 3 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, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
if { [skip_cplus_tests] } { continue }
|
|
|
|
standard_testfile hang1.cc hang2.cc hang3.cc
|
|
|
|
if {[prepare_for_testing "failed to prepare" $testfile \
|
|
[list $srcfile $srcfile2 $srcfile3] {debug c++}]} {
|
|
return -1
|
|
}
|
|
|
|
# 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_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 (incorrect)
|
|
# 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.
|
|
|
|
# This checks that GDB recognizes when a structure is about to be
|
|
# overwritten, and refuses, with a complaint.
|
|
gdb_test "print var_in_b" " = 1729" "doesn't overwrite struct type"
|
|
|
|
# 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"
|