* Re: RFA: test for GDB C++ STABS problem
@ 2002-05-01 21:26 Michael Elizabeth Chastain
2002-05-02 0:02 ` Jim Blandy
0 siblings, 1 reply; 3+ messages in thread
From: Michael Elizabeth Chastain @ 2002-05-01 21:26 UTC (permalink / raw)
To: gdb-patches, jimb
This patch is approved, with one optional change request. That is to say,
you can commit it as is, or you can make the change.
The optional change is to add an initialization for "var_in_b"
to a nonzero value such as 100. That way, the test is less likely
to succeed by accident. I tried this and it did not affect the
test results.
Here are my testbed results (native i686-pc-linux-gnu gdb HEAD):
2.95.3 -gdwarf-2 PASS
2.96-rh -gdwarf-2 PASS
3.0.4 -gdwarf-2 ERROR: process no longer exists
gcc-3_1-branch -gdwarf-2 PASS
HEAD -gdwarf-2 PASS
2.95.3 -gstabs+ FAIL (timeout)
2.96-rh -gstabs+ FAIL (timeout)
3.0.4 -gstabs+ FAIL (timeout)
gcc-3_1-branch -gstabs+ FAIL (timeout)
HEAD -gstabs+ FAIL (timeout)
As always, I appreciate your essays in the comment section.
Michael C
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: RFA: test for GDB C++ STABS problem
2002-05-01 21:26 RFA: test for GDB C++ STABS problem Michael Elizabeth Chastain
@ 2002-05-02 0:02 ` Jim Blandy
0 siblings, 0 replies; 3+ messages in thread
From: Jim Blandy @ 2002-05-02 0:02 UTC (permalink / raw)
To: Michael Elizabeth Chastain; +Cc: gdb-patches
Michael Elizabeth Chastain <mec@shout.net> writes:
> This patch is approved, with one optional change request. That is to say,
> you can commit it as is, or you can make the change.
>
> The optional change is to add an initialization for "var_in_b"
> to a nonzero value such as 100. That way, the test is less likely
> to succeed by accident. I tried this and it did not affect the
> test results.
Well, we're really testing that the command completes at all, not that
it does anything in particular before it returns. But you're right
that zero is an inauspicious value; I've made the change, and
committed the patch.
> As always, I appreciate your essays in the comment section.
It's nice to know somebody reads them!
^ permalink raw reply [flat|nested] 3+ messages in thread
* RFA: test for GDB C++ STABS problem
@ 2002-05-01 18:20 Jim Blandy
0 siblings, 0 replies; 3+ messages in thread
From: Jim Blandy @ 2002-05-01 18:20 UTC (permalink / raw)
To: gdb-patches
This one was fun! Fix on the way. The test contains an explanation
of the problem.
gdb/testsuite/ChangeLog:
2002-05-01 Jim Blandy <jimb@redhat.com>
* 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;
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-05-02 7:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-01 21:26 RFA: test for GDB C++ STABS problem Michael Elizabeth Chastain
2002-05-02 0:02 ` Jim Blandy
-- strict thread matches above, loose matches on Subject: below --
2002-05-01 18:20 Jim Blandy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox