* gdb.c++/psmang.exp: Doc fix.

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index d18352a..fa5055d 100644 (file)
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -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.
 

diff --git a/gdb/testsuite/gdb.c++/psmang.exp b/gdb/testsuite/gdb.c++/psmang.exp
index f653b0b..31dd346 100644 (file)
--- a/gdb/testsuite/gdb.c++/psmang.exp
+++ b/gdb/testsuite/gdb.c++/psmang.exp
@@ -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
@@ -118,6 +120,14 @@
 # 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