Re: -include -g broken with current CVS (testcase for PR 771)

[Neil Booth <neilb at earthling dot net>]

Would someone with good knowledge of the C front ends help me a bit here?

Andreas Jaeger wrote:-

> gromit:/tmp $ /opt/gcc-2.97.test/bin/gcc t.c
> gromit:/tmp $ /opt/gcc-2.97.test/bin/gcc -include t.h t.c
> In file included from t.c:1:
> t.h:2:2: warning: #warning "Just a test"
> gromit:/tmp $ /opt/gcc-2.97.test/bin/gcc -include t.h t.c -g
> t.h:1: Internal error: Segmentation fault.
>    Please submit a full bug report.
>    See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
> gromit:/tmp $ exit

OK, I know what's causing this, but am not sure of the right fix.

Normally, toplev.c goes through like this:

compile_file				(toplev.c)
  init_parse				(c-parse.c)
    init_c_lex				(c-lex.c)
      cpp_start_read			(cppinit.c)
       debug_start_source_file		(dbxout.c)  [Normally skipped]
  dbxout_init				(dbxout.c)
  yyparse				(c-parse.c)
   ... debug_start_source_file		(dbxout.c)  [After #include]


In this scenario, cpp_start_read calls cb_enter_file initially,
and cb_enter_file does not call debug_start_source_file because
the main file is the first on the buffer stack (ip->prev == 0).
Thus debug_start_source_file is only called later, from yyparse,
_after_ dbxout_init.

However, when a file is "-include"d, cpp_start_read churns through it
and amongst other things does a cb_enter_file on the file.  This
means that debug_start_source_file is called before dbxout_init has
had a chance to set itself up (see above).

What's the correct fix here?  To move dbxout_init earlier within
toplev.c?  Or should cb_enter_file not be creating debug info for
-included files?  Or should we move the call to cpp_start_read later?

Someone with a better knowledge of the C front end needs to help me
with this.  Zack?

Neil.