OpenE2K/binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

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

Browse Source 
test.
This commit is contained in:
Jim Blandy 2002-12-21 22:56:56 +00:00
parent 2213a65dbc
commit f0708dbbc4
4 changed files with 532 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
gdb/testsuite/ChangeLog
View File

@ -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.

216
gdb/testsuite/gdb.c++/psmang.exp Normal file
View File

@ -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.*"

159
gdb/testsuite/gdb.c++/psmang1.cc Normal file
View File

@ -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;

152
gdb/testsuite/gdb.c++/psmang2.cc Normal file
View File

@ -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;