From 4aa5781cee1b26b25c2cbf0f7c653b40dc34b0b5 Mon Sep 17 00:00:00 2001 From: Jim Blandy Date: Sat, 21 Dec 2002 22:56:56 +0000 Subject: [PATCH] * gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New test. --- gdb/testsuite/ChangeLog | 5 + gdb/testsuite/gdb.c++/psmang.exp | 216 +++++++++++++++++++++++++++++++++++++++ gdb/testsuite/gdb.c++/psmang1.cc | 159 ++++++++++++++++++++++++++++ gdb/testsuite/gdb.c++/psmang2.cc | 152 +++++++++++++++++++++++++++ 4 files changed, 532 insertions(+) create mode 100644 gdb/testsuite/gdb.c++/psmang.exp create mode 100644 gdb/testsuite/gdb.c++/psmang1.cc create mode 100644 gdb/testsuite/gdb.c++/psmang2.cc diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index c2a5982ab7..d18352aa1b 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,8 @@ +2002-12-21 Jim Blandy + + * gdb.c++/psmang.exp, gdb.c++/psmang1.cc, gdb.c++/psmang2.cc: New + test. + 2002-12-20 David Carlton * 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 0000000000..f653b0b3ef --- /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 +# +# * 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 or 's::method1 +# (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, --- 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 0000000000..19a9283bbb --- /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 0000000000..b9b1bb55b1 --- /dev/null +++ b/gdb/testsuite/gdb.c++/psmang2.cc @@ -0,0 +1,152 @@ +#include + +/* 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; -- 2.11.0