* gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New

test.

4 files changed, 532 insertions, 0 deletions

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index c2a5982..d18352a 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2002-12-21  Jim Blandy  <jimb@redhat.com>
+
+	* gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New
+	test.
+
 2002-12-20  David Carlton  <carlton@math.stanford.edu>
 
 	* gdb.c++/annota2.exp: KFAIL annotate-quit.
diff --git a/gdb/testsuite/gdb.c++/psmang.exp b/gdb/testsuite/gdb.c++/psmang.exp
new file mode 100644
index 0000000..f653b0b
--- /dev/null
+++ b/gdb/testsuite/gdb.c++/psmang.exp
@@ -0,0 +1,216 @@
+# Copyright 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
+
+# This file is part of the gdb testsuite
+
+# Looking up methods by name, in programs with multiple compilation units.
+
+# ====== PLEASE BE VERY CAREFUL WHEN CHANGING THIS TEST. =====
+#
+# The bug we're testing for (circa October 2002) is very sensitive to
+# various conditions that are hard to control directly in the test
+# suite.  If you change the test, please revert this change, and make
+# sure the test still fails:
+#
+# 2002-08-29  Jim Blandy  <jimb@redhat.com>
+# 
+# 	* symtab.c (lookup_symbol_aux): In the cases where we find a
+# 	minimal symbol of an appropriate name and use its address to
+# 	select a symtab to read and search, use `name' (as passed to us)
+# 	as the demangled name when searching the symtab's global and
+# 	static blocks, not the minsym's name.
+#
+# The original bug was that you'd try to set a breakpoint on a method
+# (e.g., `break s::method1'), and you'd get an error, but if you
+# repeated the command, it would work the second time:
+#   
+#   (gdb) break s::method1
+#   the class s does not have any method named method1
+#   Hint: try 's::method1<TAB> or 's::method1<ESC-?>
+#   (Note leading single quote.)
+#   (gdb) break s::method1
+#   Breakpoint 1 at 0x804841b: file psmang1.cc, line 13.
+#   (gdb) 
+#
+# 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
+# minsym's address to find_pc_sect_symtab to look up the symtab
+# (causing the compilation unit's full symbols to be read in), and
+# then look up the symbol in that symtab's global block.  All that is
+# correct.  However, it would pass the minsym's name as the NAME
+# argument to lookup_block_symbol; a minsym's name is mangled, whereas
+# lookup_block_symbol's NAME argument should be demangled.
+#
+# This is a pretty simple bug, but it turns out to be a bear to
+# construct a test for.  That's why this test case is so delicate.  If
+# you can see how to make it less so, please contribute a patch.
+#
+# Here are the twists:
+#
+# The bug only manifests itself when we call lookup_symbol to look up
+# a method name (like "s::method1" or "s::method2"), and that method's
+# definition is in a compilation unit for which we have read partial
+# symbols, but not full symbols.  The partial->full conversion must be
+# caused by that specific lookup.  (If we already have full symbols
+# for the method's compilation unit, we won't need to look up the
+# minsym, find the symtab for the minsym's address, and then call
+# lookup_block_symbol; it's that last call where things go awry.)
+#
+# Now, when asked to set a breakpoint at `s::method1', GDB will first
+# look up `s' to see if that is, in fact, the name of a class, and
+# then look up 's::method1'.  So we have to make sure that looking up
+# `s' doesn't cause full symbols to be read for the compilation unit
+# containing the definition of `s::method1'.
+#
+# The partial symbol tables for `psmang1.cc' and `psmang2.cc' will
+# both have entries for `s'; GDB will read full symbols for whichever
+# compilation unit's partial symbol table appears first in the
+# objfile's list.  The order in which compilation units appear in the
+# partial symbol table list depends on how the program is linked, and
+# how the debug info reader does the partial symbol scan.  Ideally,
+# the test shouldn't rely on them appearing in any particular order.
+#
+# So, since we don't know which compilation unit's full symbols are
+# going to get read, we simply try looking up one method from each of
+# the two compilation units.  One of them has to come after the other
+# in the partial symbol table list, so whichever comes later will
+# still need its partial symbols read by the time we go to look up
+# 's::methodX'.
+#
+# Second twist: don't move the common definition of `struct s' into a
+# header file.  If the compiler emits identical stabs for the
+# #inclusion of that header file into psmang1.cc and into psmang2.cc,
+# then the linker will do stabs compression, and replace one of the
+# BINCL/EINCL regions with an EXCL stab, pointing to the other
+# BINCL/EINCL region.  GDB will read this, and record that the
+# compilation unit that got the EXCL depends on the compilation unit
+# that kept the BINCL/EINCL.  Then, when it decides it needs to read
+# full symbols for the former, it'll also read full symbols for the
+# latter.  Now, if it just so happens that the compilation unit that
+# got the EXCL is also the first one with a definition of `s' in the
+# partial symbol table list, then that first probe for `s' will cause
+# both compilation units' full symbols to be read --- again defeating
+# the test.
+#
+# We could work around this by having three compilation units, or by
+# ensuring that the header file produces different stabs each time
+# it's #included, but it seems simplest just to avoid compilation unit
+# dependencies altogether, drop the header file, and duplicate the
+# (pretty trivial) struct definition.
+#
+# Note that #including any header file at all into both compilation
+# units --- say, <stdio.h> --- could create this sort of dependency.
+#
+# 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
+# might search a block, depending on how it was constructed:
+#
+# linear search.  In this case, this bug will never manifest itself,
+# since we check every symbol against NAME using SYMBOL_MATCHES_NAME.
+# Since that macro checks its second argument (NAME) against both the
+# mangled and demangled names of the symbol, this will always find the
+# symbol successfully, so, no bug.
+#
+# hash table.  If both the mangled and demangled names hash to the
+# same bucket, then you'll again find the symbol "by accident", since
+# we search the entire bucket using SYMBOL_SOURCE_NAME.  Since GDB
+# chooses the number of buckets based on the number of symbols, small
+# compilation units may have only one hash bucket; in this case, the
+# search always succeeds, even though we hashed on the wrong name.
+# This test works around that by having a lot of dummy variables,
+# making it less likely that the mangled and demangled names fall in
+# the same bucket.
+#
+# binary search.  (GDB 5.2 produced these sorts of blocks, and this
+# test tries to detect the bug there, but subsequent versions of GDB
+# almost never build them, and they may soon be removed entirely.)  In
+# this case, the symbols in the block are sorted by their
+# SYMBOL_SOURCE_NAME (whose behavior depends on the current demangling
+# setting, so that's wrong, but let's try to stay focussed).
+# lookup_block_symbol does a binary search comparing NAME with
+# SYMBOL_SOURCE_NAME until the range has been narrowed down to only a
+# few symbols; then it starts a linear search forward from the lower
+# end of that range, until it reaches a symbol whose
+# SYMBOL_SOURCE_NAME follows NAME in lexicographic order.  This means
+# that, if you're doing a binary search for a mangled name in a block
+# sorted by SYMBOL_SOURCE_NAME, you might find the symbol `by
+# accident' if the mangled and demangled names happen to fall near
+# each other in the ordering.  The initial version of this patch used
+# a class called `S'; all the other symbols in the compilation unit
+# started with lower-case letters, so the demangled name `S::method1'
+# sorted at the same place as the mangled name `_ZN1S7method1Ev': at
+# the very beginning.  Using a lower-case 's' as the name ensures that
+# the demangled name falls after all the dummy symbols introduced for
+# the hash table, as described above.
+#
+# This is all so tortured, someone will probably come up with still
+# other ways this test could fail to do its job.  If you need to make
+# revisions, please be very careful.
+
+if $tracelevel then {
+    strace $tracelevel
+}
+
+#
+# test running programs
+#
+
+set prms_id 0
+set bug_id 0
+
+if { [skip_cplus_tests] } { continue }
+
+set testfile "psmang"
+set binfile ${objdir}/${subdir}/${testfile}
+
+if [get_compiler_info ${binfile} "c++"] {
+    return -1;
+}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${testfile}1.cc" "${testfile}1.o" object {debug c++}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${testfile}2.cc" "${testfile}2.o" object {debug c++}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if  { [gdb_compile "${testfile}1.o ${testfile}2.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}
+
+gdb_test "break s::method1" "Breakpoint .* at .*: file .*psmang1.cc.*"
+
+# We have to exit and restart GDB here, to make sure that all the
+# compilation units are psymtabs again.
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+gdb_test "break s::method2" "Breakpoint .* at .*: file .*psmang2.cc.*"
diff --git a/gdb/testsuite/gdb.c++/psmang1.cc b/gdb/testsuite/gdb.c++/psmang1.cc
new file mode 100644
index 0000000..19a9283
--- /dev/null
+++ b/gdb/testsuite/gdb.c++/psmang1.cc
@@ -0,0 +1,159 @@
+/* Do not move this definition into a header file!  See the comments
+   in psmang.exp.  */
+struct s
+{
+  int value;
+  void method1 (void);
+  void method2 (void);
+};
+
+void
+s::method1 ()
+{
+  value = 42;
+}
+
+int
+main (int argc, char **argv)
+{
+  s si;
+
+  si.method1 ();
+  si.method2 ();
+}
+
+
+/* The presence of these variables ensures there will be so many
+   symbols in psmang1.cc's symtab's global block that it will have a
+   non-trivial hash table.  When there are only a very few symbols,
+   the block only has one hash bucket, so even if we compute the hash
+   value for the wrong symbol name, we'll still find a symbol that
+   matches.  */
+int ax;
+int bx;
+int a1x;
+int b1x;
+int a2x;
+int b2x;
+int a12x;
+int b12x;
+int a3x;
+int b3x;
+int a13x;
+int b13x;
+int a23x;
+int b23x;
+int a123x;
+int b123x;
+int a4x;
+int b4x;
+int a14x;
+int b14x;
+int a24x;
+int b24x;
+int a124x;
+int b124x;
+int a34x;
+int b34x;
+int a134x;
+int b134x;
+int a234x;
+int b234x;
+int a1234x;
+int b1234x;
+int a5x;
+int b5x;
+int a15x;
+int b15x;
+int a25x;
+int b25x;
+int a125x;
+int b125x;
+int a35x;
+int b35x;
+int a135x;
+int b135x;
+int a235x;
+int b235x;
+int a1235x;
+int b1235x;
+int a45x;
+int b45x;
+int a145x;
+int b145x;
+int a245x;
+int b245x;
+int a1245x;
+int b1245x;
+int a345x;
+int b345x;
+int a1345x;
+int b1345x;
+int a2345x;
+int b2345x;
+int a12345x;
+int b12345x;
+int a6x;
+int b6x;
+int a16x;
+int b16x;
+int a26x;
+int b26x;
+int a126x;
+int b126x;
+int a36x;
+int b36x;
+int a136x;
+int b136x;
+int a236x;
+int b236x;
+int a1236x;
+int b1236x;
+int a46x;
+int b46x;
+int a146x;
+int b146x;
+int a246x;
+int b246x;
+int a1246x;
+int b1246x;
+int a346x;
+int b346x;
+int a1346x;
+int b1346x;
+int a2346x;
+int b2346x;
+int a12346x;
+int b12346x;
+int a56x;
+int b56x;
+int a156x;
+int b156x;
+int a256x;
+int b256x;
+int a1256x;
+int b1256x;
+int a356x;
+int b356x;
+int a1356x;
+int b1356x;
+int a2356x;
+int b2356x;
+int a12356x;
+int b12356x;
+int a456x;
+int b456x;
+int a1456x;
+int b1456x;
+int a2456x;
+int b2456x;
+int a12456x;
+int b12456x;
+int a3456x;
+int b3456x;
+int a13456x;
+int b13456x;
+int a23456x;
+int b23456x;
+int a123456x;
+int b123456x;
diff --git a/gdb/testsuite/gdb.c++/psmang2.cc b/gdb/testsuite/gdb.c++/psmang2.cc
new file mode 100644
index 0000000..b9b1bb5
--- /dev/null
+++ b/gdb/testsuite/gdb.c++/psmang2.cc
@@ -0,0 +1,152 @@
+#include <stdio.h>
+
+/* Do not move this definition into a header file!  See the comments
+   in psmang.exp.  */
+struct s
+{
+  int value;
+  void method1 (void);
+  void method2 (void);
+};
+
+void
+s::method2 (void)
+{
+  printf ("%d\n", value);
+}
+
+
+/* The presence of these variables ensures there will be so many
+   symbols in psmang2.cc's symtab's global block that it will have a
+   non-trivial hash table.  When there are only a very few symbols,
+   the block only has one hash bucket, so even if we compute the hash
+   value for the wrong symbol name, we'll still find a symbol that
+   matches.  */
+int a;
+int b;
+int a1;
+int b1;
+int a2;
+int b2;
+int a12;
+int b12;
+int a3;
+int b3;
+int a13;
+int b13;
+int a23;
+int b23;
+int a123;
+int b123;
+int a4;
+int b4;
+int a14;
+int b14;
+int a24;
+int b24;
+int a124;
+int b124;
+int a34;
+int b34;
+int a134;
+int b134;
+int a234;
+int b234;
+int a1234;
+int b1234;
+int a5;
+int b5;
+int a15;
+int b15;
+int a25;
+int b25;
+int a125;
+int b125;
+int a35;
+int b35;
+int a135;
+int b135;
+int a235;
+int b235;
+int a1235;
+int b1235;
+int a45;
+int b45;
+int a145;
+int b145;
+int a245;
+int b245;
+int a1245;
+int b1245;
+int a345;
+int b345;
+int a1345;
+int b1345;
+int a2345;
+int b2345;
+int a12345;
+int b12345;
+int a6;
+int b6;
+int a16;
+int b16;
+int a26;
+int b26;
+int a126;
+int b126;
+int a36;
+int b36;
+int a136;
+int b136;
+int a236;
+int b236;
+int a1236;
+int b1236;
+int a46;
+int b46;
+int a146;
+int b146;
+int a246;
+int b246;
+int a1246;
+int b1246;
+int a346;
+int b346;
+int a1346;
+int b1346;
+int a2346;
+int b2346;
+int a12346;
+int b12346;
+int a56;
+int b56;
+int a156;
+int b156;
+int a256;
+int b256;
+int a1256;
+int b1256;
+int a356;
+int b356;
+int a1356;
+int b1356;
+int a2356;
+int b2356;
+int a12356;
+int b12356;
+int a456;
+int b456;
+int a1456;
+int b1456;
+int a2456;
+int b2456;
+int a12456;
+int b12456;
+int a3456;
+int b3456;
+int a13456;
+int b13456;
+int a23456;
+int b23456;
+int a123456;
+int b123456;