Re: Still a problem with debug output, with functions with #line inthe middle, on mainline

[Daniel Berlin <dan at dberlin dot org>]

On Wed, 30 Jan 2002, Neil Booth wrote:

> Daniel Berlin wrote:-
> 
> > This is because cb_file_change only calls start_source_file if map != NULL 
> > (the first file change has map == NULL).
> > So it never asks the debug info to output info about it.
> > 
> > This fixes it.
> > Index: c-lex.c
> > ===================================================================
> > RCS file: /cvs/gcc/egcs/gcc/c-lex.c,v
> > retrieving revision 1.163
> > diff -c -3 -p -w -B -b -r1.163 c-lex.c
> > *** c-lex.c     2001/12/31 04:13:35     1.163
> > --- c-lex.c     2002/01/30 21:25:19
> > *************** cb_file_change (pfile, new_map)
> > *** 265,271 ****
> > --- 265,274 ----
> >         /* Don't stack the main buffer on the input stack;
> >          we already did in compile_file.  */
> >         if (map == NULL)
> > +       {
> >           main_input_filename = new_map->to_file;
> > +         (*debug_hooks->start_source_file) (lineno, new_map->to_file);
> > +       }
> >         else
> >         {
> >           lineno = SOURCE_LINE (new_map - 1, new_map->from_line - 1);
> 
> What makes the current code work when there isn't a line change? 
The fact that we usually hit a line change before we hit code, because of 
include files?
IE it doesn't work, we just don't notice.

> I don't clearly see how this case is different to the "normal" case. 
Which normal case?
> Or
> is it a case of some code in the debug routines using the global
> filename variables (or a copy thereof)?
Nope, it's a case of never telling the debug routines that a new file 
started.

Breakpoint dwarf2out_start_source_file for your test (before my patch), 
and you'll see it's not called for "test.c", only foo.c and bar.c
This is because the start_source_file was only in the else block above, so 
it never called it for the first time we saw the change to main input 
file.

> 
> Neil.
>