[Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[Jim Blandy]

[-- Attachment #1: Type: text/plain, Size: 33 bytes --]


Ping on this test suite patch.


[-- Attachment #2: Type: message/rfc822, Size: 18046 bytes --]

From: Jim Blandy <jimb@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: Add tests for lookup_symbol_aux bug
Date: Fri, 4 Oct 2002 22:38:58 -0500
Message-ID: <200210050338.g953cwK15265@zenia.red-bean.com>


2002-10-04  Jim Blandy  <jimb@redhat.com>

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

Index: gdb/testsuite/gdb.c++/psmang.exp
===================================================================
RCS file: psmang.exp
diff -N psmang.exp
*** gdb/testsuite/gdb.c++/psmang.exp	Thu Aug 24 02:00:32 2000
--- gdb/testsuite/gdb.c++/psmang.exp	Fri Oct  4 20:44:04 2002
***************
*** 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.*"
Index: gdb/testsuite/gdb.c++/psmang1.cc
===================================================================
RCS file: psmang1.cc
diff -N psmang1.cc
*** gdb/testsuite/gdb.c++/psmang1.cc	Thu Aug 24 02:00:32 2000
--- gdb/testsuite/gdb.c++/psmang1.cc	Fri Oct  4 20:44:04 2002
***************
*** 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;
Index: gdb/testsuite/gdb.c++/psmang2.cc
===================================================================
RCS file: psmang2.cc
diff -N psmang2.cc
*** gdb/testsuite/gdb.c++/psmang2.cc	Thu Aug 24 02:00:32 2000
--- gdb/testsuite/gdb.c++/psmang2.cc	Fri Oct  4 20:44:04 2002
***************
*** 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;

Re: [Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[David Carlton]

On 20 Dec 2002 13:32:29 -0500, Jim Blandy <jimb@redhat.com> said:

> Ping on this test suite patch.

I thought this one had already been approved!  I've been running it in
a branch, and it's already uncovered one unrelated bug for me (in
lookup_partial_symbol); I hadn't realized it wasn't in the mainline.

Now that I can approve C++ testsuite patches, I'll approve it for you.

David Carlton
carlton@math.stanford.edu

Re: [Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[Jim Blandy]

David Carlton <carlton@math.stanford.edu> writes:

> On 20 Dec 2002 13:32:29 -0500, Jim Blandy <jimb@redhat.com> said:
> 
> > Ping on this test suite patch.
> 
> I thought this one had already been approved!  I've been running it in
> a branch, and it's already uncovered one unrelated bug for me (in
> lookup_partial_symbol); I hadn't realized it wasn't in the mainline.
> 
> Now that I can approve C++ testsuite patches, I'll approve it for you.

Great!  You may have approved it, and I missed the message.  It's
committed now.

Re: [Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[Michael Elizabeth Chastain]

Jim Blandy writes:

> That particular .exp file is 87% comments and blank lines.  :)

I know.  :)

> Okay, I've committed this patch: ...

You are a beautiful man.

And I am grateful to you for your philosophical musing one night in
Toronto regarding the development of tastes versus skills.  You ...
<i>illuminated</i> me.

Michael C
too tired

Re: [Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[David Carlton]

On Sat, 21 Dec 2002 00:59:35 -0600, Michael Elizabeth Chastain <mec@shout.net> said:

> It feels a little strange to have a test which will PASS almost all the
> time, even if gdb is broken.

For what it's worth, this test has already caught an unrelated bug, so
it's having surprising benefits.  I think probably the test suite
doesn't pound on the partial symbol table as much as it could, so even
narrowly targeted partial symbol tests like this one are useful.

> (For instance, we could add some maint commands to gdb to force
> specific algorithmic paths in the symbol table reader so that test
> scripts can exercise them).

That sounds like an interesting idea.  I do think that unit tests are
useful, and unfortunately some parts of the symbol table (especially
partial symbols) are buried a bit too deep in GDB's innards to be able
to easily do unit testing on via the test suite.  Maybe maint commands
would help with that.

It would take some thinking to do well, though...

David Carlton
carlton@math.stanford.edu

Re: [Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[Jim Blandy]

Michael Elizabeth Chastain <mec@shout.net> writes:
> Jim Blandy submits:
> 
>   2002-10-04  Jim Blandy  <jimb@redhat.com>
> 
> 	* gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New
> 	test.
> 
> This patch is approved, provided that you add one more comment.
> (It seems kinda strange to exhort Jim Blandy, of all people, to write
> more comments!)

That particular .exp file is 87% comments and blank lines.  :)

> My request is: in psmang.exp, mention whether you were testing with
> dwarf-2 or stabs+ debugging format when you saw the bug happening.
> This would be important if someone were trying to reproduce the bug.
> (I saw the bug happening with both formats).

Okay, I've committed this patch:

2002-12-21  Jim Blandy  <jimb@redhat.com>

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

Index: gdb/testsuite/gdb.c++/psmang.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.c++/psmang.exp,v
retrieving revision 1.1
diff -u -r1.1 psmang.exp
--- gdb/testsuite/gdb.c++/psmang.exp	21 Dec 2002 22:56:56 -0000	1.1
+++ gdb/testsuite/gdb.c++/psmang.exp	22 Dec 2002 02:54:00 -0000
@@ -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
@@ -117,6 +119,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

Re: [Jim Blandy <jimb@redhat.com>] RFA: Add tests for lookup_symbol_aux bug

[Michael Elizabeth Chastain]

Jim Blandy submits:

  2002-10-04  Jim Blandy  <jimb@redhat.com>

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

This patch is approved, provided that you add one more comment.
(It seems kinda strange to exhort Jim Blandy, of all people, to write
more comments!)

It's already been approved by David Carlton so you could just commit
it and then consider my request.

My request is: in psmang.exp, mention whether you were testing with
dwarf-2 or stabs+ debugging format when you saw the bug happening.
This would be important if someone were trying to reproduce the bug.
(I saw the bug happening with both formats).

It feels a little strange to have a test which will PASS almost all the
time, even if gdb is broken.  I thought about it, and I decided that
it's okay with me.  A test which PASSes all the time actually takes up
very little human attention.  Also, there is plenty of information in
the test script, so someone could improve it with a patch later in the
future.  (For instance, we could add some maint commands to gdb to force
specific algorithmic paths in the symbol table reader so that test
scripts can exercise them).

Testing: I tested this on native i686-pc-linux-gnu, with:

  gdb     => 5.2.1, gdb_5_3-branch, HEAD
  gcc     => v2 and v3
  gformat => dwarf-2, stabs+

All configurations with gdb HEAD and gdb_5_3-branch gave these results.
So did gdb 5.2.1 with gcc v2:

  PASS: gdb.c++/psmang.exp: break s::method1
  PASS: gdb.c++/psmang.exp: break s::method2

The bug was fixed before gdb 5.3 was branched so gdb_5_3-branch is okay,
and presumably gdb 5.3 itself is too.

Configurations with gdb 5.2.1 and gcc v3 gave these results:

  FAIL: gdb.c++/psmang.exp: break s::method1
  PASS: gdb.c++/psmang.exp: break s::method2

This is all as expected, no surprises.

Michael C