Re: [fortran,patch] Handle preprocessing with -g3

[Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>]

Hi FX,

FX Coudert wrote:
> The Fortran front-end currently thinks the only preprocessor lines it 
> can be given are location lines (of the form: # linenum "filename"). 
> This is not true for verbose dwarf2 debug (-g3 on a platform that uses 
> dwarf2): in that case, #define and #undef preprocessor directives are 
> included in the preprocessed file, so that they debug info can be 
> emitted for macros. The Fortran front-end not only doesn't emit such 
> debug information, but it even chokes on the preprocessor lines. This 
> patch makes us handle them and emit appropriate debug info for each 
> #define and #undef, and adds additional debug info needed to make it work.
>
> Half the patch is doing exactly that: We first encounter the #define and 
> #undef lines when loading the file; at that time, however, it's too 
> early to emit debug info (the compiler hasn't yet setup the output 
> file), so we just have to ignore them (that's the part in 
> scanner.c:load_file). Later, when we actually parse the source, we can 
> actually handle them: in next_statement [parse.c], we call about new 
> function gfc_define_undef_line [scanner.c], which calls 
> debug_hooks->define and debug_hooks->undef.
>
> The second half of the patch is needed to make it work: we need to 
> register filenames with debug_hooks->start_source_file and 
> debug_hooks->end_source_file whenever we enter a new included file and 
> exit it. We also do it for the main source file, if the debug format 
> requests it (indicated by debug_hooks->start_end_main_source_file). This 
> part was designed by looking at gcc/c-lex.c.

This patch seems to cause regressions on i386-linux and i386-darwin. 
I'm seeing new failures with literal_character_constant_*.F and 
g77/cpp5.F at -O3 -g, and your patch looks like the only possible culprit.

The failures are segfaults due to NULL pointer dereferencing in dwarf2out.c.

Cheers,
- Tobi