From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25319 invoked by alias); 24 Sep 2003 18:13:09 -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 2823 invoked from network); 24 Sep 2003 17:40:36 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 24 Sep 2003 17:40:36 -0000 Received: by zenia.home (Postfix, from userid 5433) id 4F38A20766; Wed, 24 Sep 2003 12:37:06 -0500 (EST) To: Michael Elizabeth Chastain Cc: carlton@kealia.com, gdb-patches@sources.redhat.com Subject: Re: RFA: test that GDB tolerates bad #inclusion data References: <200309231803.h8NI3b2c026041@duracef.shout.net> From: Jim Blandy Date: Wed, 24 Sep 2003 18:13:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-09/txt/msg00534.txt.bz2 I'm glad you asked me to revise this: - The test is no lenger GCC 3.2 specific; GCC 3.3 will also produce macro information that will crash GDB without the corresponding patch to macrotab.c. - The test is no longer GCC-specific at all. I have no idea what other compilers will generate for that test program, but something reasonable will happen. It now uses gdb_test_multiple for the outermost test. I tried using it for the internal error recovery too, but it got kind of upset and produced extraneous ERRORS and UNRESOLVED tests. 2003-09-23 Jim Blandy * gdb.base/lineinc.exp, gdb.base/lineinc1.h, gdb.base/lineinc2.h, gdb.base/lineinc3.h, gdb.base/lineinc.c: New tests. Index: gdb/testsuite/gdb.base/lineinc.exp =================================================================== RCS file: gdb/testsuite/gdb.base/lineinc.exp diff -N gdb/testsuite/gdb.base/lineinc.exp *** gdb/testsuite/gdb.base/lineinc.exp 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.base/lineinc.exp 24 Sep 2003 17:13:19 -0000 *************** *** 0 **** --- 1,133 ---- + # Test macro handling of #included files. + # Copyright 2003 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 + + # The test program lineinc.c contains a mix of #line directives and + # #include directives that will cause the compiler to attribute more + # than one #inclusion to the same source line. You can get similar + # effects using things like GCC's '-imacros' flag. + # + # Compiling lineinc.c with Dwarf 2 macro information will produce + # something like this: + # + # $ gcc -g3 lineinc.c -o lineinc + # $ readelf -wml lineinc + # ... + # The File Name Table: + # Entry Dir Time Size Name + # 1 0 0 0 lineinc.c + # 2 0 0 0 lineinc1.h + # 3 0 0 0 lineinc2.h + # 4 0 0 0 lineinc3.h + # ... + # Contents of the .debug_macinfo section: + # + # DW_MACINFO_start_file - lineno: 0 filenum: 1 + # DW_MACINFO_define - lineno : 1 macro : __VERSION__ "3.2 20020903 (Red Hat Linux 8.0 3.2-7)" + # DW_MACINFO_define - lineno : 2 macro : __USER_LABEL_PREFIX__ + # ... + # DW_MACINFO_define - lineno : 1 macro : __i386__ 1 + # DW_MACINFO_define - lineno : 1 macro : __tune_i386__ 1 + # DW_MACINFO_start_file - lineno: 10 filenum: 2 + # DW_MACINFO_define - lineno : 1 macro : FOO 1 + # DW_MACINFO_end_file + # DW_MACINFO_start_file - lineno: 10 filenum: 3 + # DW_MACINFO_undef - lineno : 1 macro : FOO + # DW_MACINFO_define - lineno : 2 macro : FOO 2 + # DW_MACINFO_end_file + # DW_MACINFO_start_file - lineno: 11 filenum: 4 + # DW_MACINFO_undef - lineno : 1 macro : FOO + # DW_MACINFO_define - lineno : 2 macro : FOO 3 + # DW_MACINFO_end_file + # DW_MACINFO_end_file + # $ + # + # Note how the inclusions of lineinc1.h and lineinc2.h are both + # attributed to line 10 of lineinc.c, and the #inclusion of lineinc3.h + # is attributed to line 11. This is all correct, given the #line + # directives in lineinc.c. + # + # Dwarf 2 macro information doesn't contain enough information to + # allow GDB to figure out what's really going on here --- it makes no + # mention of the #line directives --- so we just try to cope as best + # we can. If the macro table were to attribute more than one + # #inclusion to the same source line, then GDB wouldn't be able to + # tell which #included file's #definitions and #undefinitions come + # first, so it can't tell which #definitions are in scope following + # all the #inclusions. To cope with this, GDB puts all the files + # #included by a given source file in a list sorted by the line at + # which they were #included; this gives GDB the chance to detect + # multiple #inclusions at the same line, complain, and assign + # distinct, albiet incorrect, line numbers to each #inclusion. + # + # However, at one point GDB was sorting the list in reverse order, + # while the code to assign new, distinct line numbers assumed it was + # sorted in ascending order; GDB would get an internal error trying to + # read the above debugging info. + + if $tracelevel then { + strace $tracelevel + } + + set prms_id 0 + set bug_id 0 + + set testfile "lineinc" + set binfile ${objdir}/${subdir}/${testfile} + + + if {[gdb_compile "${srcdir}/${subdir}/${testfile}.c" ${binfile} executable {debug}] != ""} { + 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} + + # Any command that causes GDB to read the debugging info for the + # lineinc.c compilation unit will do here. + set test_name "tolerate macro info with multiple #inclusions per line" + send_gdb "break main\n" + gdb_expect { + -re "Breakpoint 1 at 0x.*: file .*lineinc.c.*\\.\r\n${gdb_prompt}" { + pass $test_name + } + -re ".*internal-error:.*.y or n. " { + fail $test_name + send_gdb "y\n" + gdb_expect { + -re ".*.y or n. " { + send_gdb "n\n" + exp_continue + } + -re "$gdb_prompt" { + } + timeout { + fail "$test_name (timeout)" + } + } + } + -re ".*$gdb_prompt" { + fail "$test_name (unexpected response)" + } + timeout { + fail "$test_name (timeout)" + } + } Index: gdb/testsuite/gdb.base/lineinc.c =================================================================== RCS file: gdb/testsuite/gdb.base/lineinc.c diff -N gdb/testsuite/gdb.base/lineinc.c *** gdb/testsuite/gdb.base/lineinc.c 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.base/lineinc.c 24 Sep 2003 17:13:19 -0000 *************** *** 0 **** --- 1,30 ---- + /* The following is written to tickle a specific bug in the macro + table code (now hopefully fixed), which doesn't insert new included + files in the #including file's list in the proper place. They + should be sorted by the number of the line which #included them, in + increasing order, but the sense of the comparison was reversed, so + the list ends up being built backwards. This isn't a problem by + itself, but the code to pick new, non-conflicting line numbers for + headers alleged to be #included at the same line as some other + header assumes that the list's line numbers are in ascending order. + + So, given the following input, lineinc1.h gets added to lineinc.c's + #inclusion list first, at line 10. When the debug info reader + tries to add lineinc2.h at line 10 as well, the code will notice the + duplication --- since there's only one extant element in the list, + it'll find it --- and insert it after lineinc1.h, with line 11. + Since the code is putting the list in order of descending + #inclusion line number, the list is now out of order. When we try + to #include lineinc3.h at line 11, we won't notice the duplication. */ + + #line 10 + #include "lineinc1.h" + #line 10 + #include "lineinc2.h" + #line 11 + #include "lineinc3.h" + + int + main (int argc, char **argv) + { + } Index: gdb/testsuite/gdb.base/lineinc1.h =================================================================== RCS file: gdb/testsuite/gdb.base/lineinc1.h diff -N gdb/testsuite/gdb.base/lineinc1.h *** gdb/testsuite/gdb.base/lineinc1.h 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.base/lineinc1.h 24 Sep 2003 17:13:19 -0000 *************** *** 0 **** --- 1 ---- + #define FOO 1 Index: gdb/testsuite/gdb.base/lineinc2.h =================================================================== RCS file: gdb/testsuite/gdb.base/lineinc2.h diff -N gdb/testsuite/gdb.base/lineinc2.h *** gdb/testsuite/gdb.base/lineinc2.h 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.base/lineinc2.h 24 Sep 2003 17:13:19 -0000 *************** *** 0 **** --- 1,2 ---- + #undef FOO + #define FOO 2 Index: gdb/testsuite/gdb.base/lineinc3.h =================================================================== RCS file: gdb/testsuite/gdb.base/lineinc3.h diff -N gdb/testsuite/gdb.base/lineinc3.h *** gdb/testsuite/gdb.base/lineinc3.h 1 Jan 1970 00:00:00 -0000 --- gdb/testsuite/gdb.base/lineinc3.h 24 Sep 2003 17:13:19 -0000 *************** *** 0 **** --- 1,2 ---- + #undef FOO + #define FOO 3