This is the mail archive of the
mailing list for the GDB project.
Re: RFA: tolerate bogus Dwarf macro info
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com, ezannoni at redhat dot com
- Date: Mon, 26 Sep 2005 12:28:36 -0400
- Subject: Re: RFA: tolerate bogus Dwarf macro info
- References: <email@example.com>
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
> 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,