mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-21 04:42:53 +08:00
42a4f53d2b
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
106 lines
4.9 KiB
Plaintext
106 lines
4.9 KiB
Plaintext
# Copyright 2002-2019 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"
|