OpenCores
URL https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk

Subversion Repositories openrisc_me

[/] [openrisc/] [trunk/] [gnu-src/] [gdb-6.8/] [gdb/] [testsuite/] [gdb.cp/] [hang.exp] - Blame information for rev 157

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 24 jeremybenn
#   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 .
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}.C" "${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"

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.