From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1996 invoked by alias); 26 Sep 2005 16:29: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 1780 invoked by uid 22791); 26 Sep 2005 16:28:38 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 26 Sep 2005 16:28:38 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EJvqG-0001iQ-Aq; Mon, 26 Sep 2005 12:28:36 -0400 Date: Mon, 26 Sep 2005 16:29:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com, ezannoni@redhat.com Subject: Re: RFA: tolerate bogus Dwarf macro info Message-ID: <20050926162836.GA6510@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com, ezannoni@redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00228.txt.bz2 On Mon, Sep 26, 2005 at 09:18:35AM -0700, Jim Blandy wrote: > The versions of GCC released with Fedora Core 4 produce Dwarf > preprocessor macro information that uses incorrect file numbers. GDB > doesn't handle this well --- it crashes. The patch below allows GDB > to tolerate the ill-formed macro information. > > At the bottom of this message is the output I get from 'readelf -wilm' > (that is, .debug_info, line numbers, and macros) when applied to > libiberty/xstrerror.o. As the compilation unit's DW_AT_producer > attribute says, this is info produced by GCC 4.0.1; info from GCC > 4.0.0 has the same sort of problem. > > Note that the line number info's file table has entries for file > numbers 1 through 21. However, note the line towards the end that > reads: > > DW_MACINFO_start_file - lineno: 42 filenum: 22 > > The previous DW_MACINFO_start_file seems to have its number wrong, > too: LIBIBERTY_H is defined at line 36 of libiberty.h, which is file > 20, not 21. So I worried for a moment that this was some off-by-one > weirdness caused by Dwarf line info file numbers starting with one, > not zero. But the file numbers at the beginning of the macro info are > right: _STDIO_H is indeed #defined at line 27 of file 2 (stdio.h). So > whether or not GDB is confused about how to interpret line numbers (I > think it's right), GCC is definitely broken. It breaks at stdarg.h. Presumably this has something to do with #include_next; have you submitted a GCC bug report to go with this? > This failure is covered by the existing test suite, if the test > programs are compiled with the -g3 flag. But since no one really tests that way, it's effectively not covered. Could you add a manual test case to the existing DWARF unit tests, please? -- Daniel Jacobowitz CodeSourcery, LLC