1# Copyright 2002-2023 Free Software Foundation, Inc. 2 3# This program is free software; you can redistribute it and/or modify 4# it under the terms of the GNU General Public License as published by 5# the Free Software Foundation; either version 3 of the License, or 6# (at your option) any later version. 7# 8# This program is distributed in the hope that it will be useful, 9# but WITHOUT ANY WARRANTY; without even the implied warranty of 10# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the 11# GNU General Public License for more details. 12# 13# You should have received a copy of the GNU General Public License 14# along with this program. If not, see <http://www.gnu.org/licenses/>. 15 16# This file is part of the gdb testsuite 17 18# Looking up methods by name, in programs with multiple compilation units. 19 20# ====== PLEASE BE VERY CAREFUL WHEN CHANGING THIS TEST. ===== 21# 22# The bug we're testing for (circa October 2002) is very sensitive to 23# various conditions that are hard to control directly in the test 24# suite. If you change the test, please revert this change, and make 25# sure the test still fails: 26# 27# 2002-08-29 Jim Blandy <jimb@redhat.com> 28# 29# * symtab.c (lookup_symbol_aux): In the cases where we find a 30# minimal symbol of an appropriate name and use its address to 31# select a symtab to read and search, use `name' (as passed to us) 32# as the demangled name when searching the symtab's global and 33# static blocks, not the minsym's name. 34# 35# The original bug was that you'd try to set a breakpoint on a method 36# (e.g., `break s::method1'), and you'd get an error, but if you 37# repeated the command, it would work the second time: 38# 39# (gdb) break s::method1 40# the class s does not have any method named method1 41# Hint: try 's::method1<TAB> or 's::method1<ESC-?> 42# (Note leading single quote.) 43# (gdb) break s::method1 44# Breakpoint 1 at 0x804841b: file psmang1.cc, line 13. 45# (gdb) 46# 47# We observed this bug first using Stabs, and then using Dwarf 2. 48# 49# The problem was in lookup_symbol_aux: when looking up s::method1, it 50# would fail to find it in any symtabs, find the minsym with the 51# corresponding mangled name (say, `_ZN1S7method1Ev'), pass the 52# minsym's address to find_pc_sect_symtab to look up the symtab 53# (causing the compilation unit's full symbols to be read in), and 54# then look up the symbol in that symtab's global block. All that is 55# correct. However, it would pass the minsym's name as the NAME 56# argument to lookup_block_symbol; a minsym's name is mangled, whereas 57# lookup_block_symbol's NAME argument should be demangled. 58# 59# This is a pretty simple bug, but it turns out to be a bear to 60# construct a test for. That's why this test case is so delicate. If 61# you can see how to make it less so, please contribute a patch. 62# 63# Here are the twists: 64# 65# The bug only manifests itself when we call lookup_symbol to look up 66# a method name (like "s::method1" or "s::method2"), and that method's 67# definition is in a compilation unit for which we have read partial 68# symbols, but not full symbols. The partial->full conversion must be 69# caused by that specific lookup. (If we already have full symbols 70# for the method's compilation unit, we won't need to look up the 71# minsym, find the symtab for the minsym's address, and then call 72# lookup_block_symbol; it's that last call where things go awry.) 73# 74# Now, when asked to set a breakpoint at `s::method1', GDB will first 75# look up `s' to see if that is, in fact, the name of a class, and 76# then look up 's::method1'. So we have to make sure that looking up 77# `s' doesn't cause full symbols to be read for the compilation unit 78# containing the definition of `s::method1'. 79# 80# The partial symbol tables for `psmang1.cc' and `psmang2.cc' will 81# both have entries for `s'; GDB will read full symbols for whichever 82# compilation unit's partial symbol table appears first in the 83# objfile's list. The order in which compilation units appear in the 84# partial symbol table list depends on how the program is linked, and 85# how the debug info reader does the partial symbol scan. Ideally, 86# the test shouldn't rely on them appearing in any particular order. 87# 88# So, since we don't know which compilation unit's full symbols are 89# going to get read, we simply try looking up one method from each of 90# the two compilation units. One of them has to come after the other 91# in the partial symbol table list, so whichever comes later will 92# still need its partial symbols read by the time we go to look up 93# 's::methodX'. 94# 95# Second twist: don't move the common definition of `struct s' into a 96# header file. If the compiler emits identical stabs for the 97# #inclusion of that header file into psmang1.cc and into psmang2.cc, 98# then the linker will do stabs compression, and replace one of the 99# BINCL/EINCL regions with an EXCL stab, pointing to the other 100# BINCL/EINCL region. GDB will read this, and record that the 101# compilation unit that got the EXCL depends on the compilation unit 102# that kept the BINCL/EINCL. Then, when it decides it needs to read 103# full symbols for the former, it'll also read full symbols for the 104# latter. Now, if it just so happens that the compilation unit that 105# got the EXCL is also the first one with a definition of `s' in the 106# partial symbol table list, then that first probe for `s' will cause 107# both compilation units' full symbols to be read --- again defeating 108# the test. 109# 110# We could work around this by having three compilation units, or by 111# ensuring that the header file produces different stabs each time 112# it's #included, but it seems simplest just to avoid compilation unit 113# dependencies altogether, drop the header file, and duplicate the 114# (pretty trivial) struct definition. 115# 116# Note that #including any header file at all into both compilation 117# units --- say, <stdio.h> --- could create this sort of dependency. 118# 119# This is the aspect of the test which the debug format is most likely 120# to affect, I think. The different formats create different kinds of 121# inter-CU dependencies, which could mask the bug. It might be 122# possible for the test to check that at least one of the partial 123# symtabs remains unread, and fail otherwise --- the failure 124# indicating that the test itself isn't going to catch the bug it was 125# meant to, not that GDB is misbehaving. 126# 127# Third twist: given the way lookup_block_symbol is written, it's 128# possible to find the symbol even when it gets passed a mangled name 129# for its NAME parameter. There are three ways lookup_block_symbol 130# might search a block, depending on how it was constructed: 131# 132# linear search. In this case, this bug will never manifest itself, 133# since we check every symbol against NAME using SYMBOL_MATCHES_NAME. 134# Since that macro checks its second argument (NAME) against both the 135# mangled and demangled names of the symbol, this will always find the 136# symbol successfully, so, no bug. 137# 138# hash table. If both the mangled and demangled names hash to the 139# same bucket, then you'll again find the symbol "by accident", since 140# we search the entire bucket using SYMBOL_SOURCE_NAME. Since GDB 141# chooses the number of buckets based on the number of symbols, small 142# compilation units may have only one hash bucket; in this case, the 143# search always succeeds, even though we hashed on the wrong name. 144# This test works around that by having a lot of dummy variables, 145# making it less likely that the mangled and demangled names fall in 146# the same bucket. 147# 148# binary search. (GDB 5.2 produced these sorts of blocks, and this 149# test tries to detect the bug there, but subsequent versions of GDB 150# almost never build them, and they may soon be removed entirely.) In 151# this case, the symbols in the block are sorted by their 152# SYMBOL_SOURCE_NAME (whose behavior depends on the current demangling 153# setting, so that's wrong, but let's try to stay focussed). 154# lookup_block_symbol does a binary search comparing NAME with 155# SYMBOL_SOURCE_NAME until the range has been narrowed down to only a 156# few symbols; then it starts a linear search forward from the lower 157# end of that range, until it reaches a symbol whose 158# SYMBOL_SOURCE_NAME follows NAME in lexicographic order. This means 159# that, if you're doing a binary search for a mangled name in a block 160# sorted by SYMBOL_SOURCE_NAME, you might find the symbol `by 161# accident' if the mangled and demangled names happen to fall near 162# each other in the ordering. The initial version of this patch used 163# a class called `S'; all the other symbols in the compilation unit 164# started with lower-case letters, so the demangled name `S::method1' 165# sorted at the same place as the mangled name `_ZN1S7method1Ev': at 166# the very beginning. Using a lower-case 's' as the name ensures that 167# the demangled name falls after all the dummy symbols introduced for 168# the hash table, as described above. 169# 170# This is all so tortured, someone will probably come up with still 171# other ways this test could fail to do its job. If you need to make 172# revisions, please be very careful. 173 174# 175# test running programs 176# 177 178 179if { [skip_cplus_tests] } { continue } 180 181standard_testfile psmang1.cc psmang2.cc 182 183if {[prepare_for_testing "failed to prepare" $testfile \ 184 [list $srcfile $srcfile2] {debug c++}]} { 185 return -1 186} 187 188gdb_test "break s::method1" "Breakpoint .* at .*: file .*psmang1.cc.*" 189 190# We have to exit and restart GDB here, to make sure that all the 191# compilation units are psymtabs again. 192 193clean_restart ${binfile} 194 195gdb_test "break s::method2" "Breakpoint .* at .*: file .*psmang2.cc.*" 196