Re: RFA: tolerate bogus Dwarf macro info

[Daniel Jacobowitz <drow at false dot org>]

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