From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20962 invoked by alias); 20 Dec 2002 18:51:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20847 invoked from network); 20 Dec 2002 18:51:25 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by 209.249.29.67 with SMTP; 20 Dec 2002 18:51:25 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id gBKIWU5h026327; Fri, 20 Dec 2002 13:32:30 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id gBKIWUYd026323; Fri, 20 Dec 2002 13:32:30 -0500 To: Fernando Nasser CC: gdb-patches@sources.redhat.com Subject: [Jim Blandy ] RFA: Add tests for lookup_symbol_aux bug From: Jim Blandy Date: Fri, 20 Dec 2002 10:54:00 -0000 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-SW-Source: 2002-12/txt/msg00589.txt.bz2 --=-=-= Content-length: 33 Ping on this test suite patch. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-length: 18024 X-From-Line: imap Mon Oct 7 13:32:30 2002 Return-Path: X-Sieve: cmu-sieve 2.0 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g953tW814196 for ; Fri, 4 Oct 2002 23:55:32 -0400 Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with SMTP id g953tVf32693 for ; Fri, 4 Oct 2002 23:55:31 -0400 Received: from sources.redhat.com (sources.redhat.com [209.249.29.67]) by mx1.redhat.com (8.11.6/8.11.6) with SMTP id g953aFX12613 for ; Fri, 4 Oct 2002 23:36:15 -0400 Received: (qmail 21613 invoked by alias); 5 Oct 2002 03:55:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Delivered-To: mailing list gdb-patches@sources.redhat.com Received: (qmail 21605 invoked from network); 5 Oct 2002 03:55:23 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 5 Oct 2002 03:55:23 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g953cwK15265; Fri, 4 Oct 2002 22:38:58 -0500 Date: Fri, 4 Oct 2002 22:38:58 -0500 Message-Id: <200210050338.g953cwK15265@zenia.red-bean.com> From: Jim Blandy To: gdb-patches@sources.redhat.com Subject: RFA: Add tests for lookup_symbol_aux bug Lines: 562 Xref: zenia.red-bean.com mail.gdb.patches:19858 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-length: 16024 2002-10-04 Jim Blandy * 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 + # + # * 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.*" 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 + + /* 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; --=-=-=--