From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26150 invoked by alias); 2 May 2002 01:20:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25929 invoked from network); 2 May 2002 01:20:38 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 2 May 2002 01:20:38 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id C00A05EA11; Wed, 1 May 2002 20:20:37 -0500 (EST) From: Jim Blandy To: gdb-patches@sources.redhat.com Subject: RFA: test for GDB C++ STABS problem Message-Id: <20020502012037.C00A05EA11@zwingli.cygnus.com> Date: Wed, 01 May 2002 18:20:00 -0000 X-SW-Source: 2002-05/txt/msg00021.txt.bz2 This one was fun! Fix on the way. The test contains an explanation of the problem. gdb/testsuite/ChangeLog: 2002-05-01 Jim Blandy * gdb.c++/hang1.C, gdb.c++/hang2.C, gdb.c++/hang.H, gdb.c++/hang.exp: New test. Index: gdb/testsuite/gdb.c++/hang.H =================================================================== RCS file: gdb/testsuite/gdb.c++/hang.H diff -N gdb/testsuite/gdb.c++/hang.H *** gdb/testsuite/gdb.c++/hang.H 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.c++/hang.H 2 May 2002 01:04:29 -0000 *************** *** 0 **** --- 1,12 ---- + struct A + { + struct B *b_ptr_in_a; + }; + + struct C + { + struct B + { + int member_of_B_in_C; + }; + }; Index: gdb/testsuite/gdb.c++/hang.exp =================================================================== RCS file: gdb/testsuite/gdb.c++/hang.exp diff -N gdb/testsuite/gdb.c++/hang.exp *** gdb/testsuite/gdb.c++/hang.exp 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.c++/hang.exp 2 May 2002 01:04:29 -0000 *************** *** 0 **** --- 1,114 ---- + # Copyright (C) 2002 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 2 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, write to the Free Software + # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + + # Please email any bugs, comments, and/or additions to this file to: + # bug-gdb@prep.ai.mit.edu + + if $tracelevel then { + strace $tracelevel + } + + set prms_id 0 + set bug_id 0 + + if { [skip_cplus_tests] } { continue } + + set testfile hang + set binfile ${objdir}/${subdir}/${testfile} + + foreach file {hang1 hang2} { + if { [gdb_compile "${srcdir}/${subdir}/${file}.C" "${file}.o" object {debug c++}] != "" } { + gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." + } + } + + if {[gdb_compile "hang1.o hang2.o" ${binfile} executable {debug c++}] != "" } { + gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." + } + + + gdb_exit + gdb_start + gdb_reinitialize_dir $srcdir/$subdir + gdb_load ${binfile} + + + # 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_FLAG_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 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. + + set timeout 10 + gdb_test "print var_in_b" " = 0" "can read debug info" Index: gdb/testsuite/gdb.c++/hang1.C =================================================================== RCS file: gdb/testsuite/gdb.c++/hang1.C diff -N gdb/testsuite/gdb.c++/hang1.C *** gdb/testsuite/gdb.c++/hang1.C 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.c++/hang1.C 2 May 2002 01:04:29 -0000 *************** *** 0 **** --- 1,3 ---- + #include "hang.H" + + int main (int argc, char **argv) { return 0; } Index: gdb/testsuite/gdb.c++/hang2.C =================================================================== RCS file: gdb/testsuite/gdb.c++/hang2.C diff -N gdb/testsuite/gdb.c++/hang2.C *** gdb/testsuite/gdb.c++/hang2.C 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.c++/hang2.C 2 May 2002 01:04:29 -0000 *************** *** 0 **** --- 1,8 ---- + #include "hang.H" + + struct B + { + int member_of_B; + }; + + int var_in_b;