--- Begin Message ---
- From: Jim Blandy <jimb at redhat dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Fri, 4 Oct 2002 22:38:58 -0500
- Subject: RFA: Add tests for lookup_symbol_aux bug
- Xref: zenia.red-bean.com mail.gdb.patches:19858
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;
--- End Message ---