* gdb.c++/psmang.exp: Doc fix.
authorJim Blandy <jimb@codesourcery.com>
Sun, 22 Dec 2002 02:58:43 +0000 (02:58 +0000)
committerJim Blandy <jimb@codesourcery.com>
Sun, 22 Dec 2002 02:58:43 +0000 (02:58 +0000)
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.c++/psmang.exp

index d18352aa1bd625bb3a8b82eab84728b4e3fdf250..fa5055d803e63197242ae1e7c6163ec7fea4e126 100644 (file)
@@ -1,5 +1,7 @@
 2002-12-21  Jim Blandy  <jimb@redhat.com>
 
+       * gdb.c++/psmang.exp: Doc fix.
+
        * gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New
        test.
 
index f653b0b3ef89ca0514d6e9897e0e8f5a3cac36a3..31dd34643f0a6fa1dac366960753e326c68ce414 100644 (file)
@@ -48,6 +48,8 @@
 #   Breakpoint 1 at 0x804841b: file psmang1.cc, line 13.
 #   (gdb) 
 #
+# We observed this bug first using Stabs, and then using Dwarf 2.
+#
 # The problem was in lookup_symbol_aux: when looking up s::method1, it
 # would fail to find it in any symtabs, find the minsym with the
 # corresponding mangled name (say, `_ZN1S7method1Ev'), pass the
 # Note that #including any header file at all into both compilation
 # units --- say, <stdio.h> --- could create this sort of dependency.
 #
+# This is the aspect of the test which the debug format is most likely
+# to affect, I think.  The different formats create different kinds of
+# inter-CU dependencies, which could mask the bug.  It might be
+# possible for the test to check that at least one of the partial
+# symtabs remains unread, and fail otherwise --- the failure
+# indicating that the test itself isn't going to catch the bug it was
+# meant to, not that GDB is misbehaving.
+#
 # Third twist: given the way lookup_block_symbol is written, it's
 # possible to find the symbol even when it gets passed a mangled name
 # for its NAME parameter.  There are three ways lookup_block_symbol