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

[Zack Weinberg <zack at codesourcery dot com>]

On Wed, Jan 30, 2002 at 04:31:47PM -0500, 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.

We can't call start_source_file that early.  The assembly output file
is not yet open, we will crash.

Program received signal SIGSEGV, Segmentation fault.
0x400647bd in _IO_vfprintf (s=0x0, 
    format=0x8483c60 "\t.section\t%s,\"%s\",@%s\n", ap=0xbffff56c)
    at vfprintf.c:270

(gdb) bt
#0  0x400647bd in _IO_vfprintf (s=0x0, 
    format=0x8483c60 "\t.section\t%s,\"%s\",@%s\n", ap=0xbffff56c)
    at vfprintf.c:270
#1  0x4006d585 in fprintf (stream=0x0, 
    format=0x8483c60 "\t.section\t%s,\"%s\",@%s\n") at fprintf.c:32
#2  0x0832852f in default_elf_asm_named_section (
    name=0x8425bec ".debug_macinfo", flags=1024)
    at varasm.c:5164
#3  0x083187ca in named_section_flags (name=0x8425bec ".debug_macinfo", 
    flags=1024) at varasm.c:415
#4  0x081060e0 in dwarf2out_start_source_file (lineno=2734686186, 
    filename=0x8563508 "20000503-1.c") at dwarf2out.c:11835
#5  0x0805902b in cb_file_change (pfile=0x853fd00, new_map=0x8563768)
    at c-lex.c:284
#6  0x080ad915 in _cpp_do_file_change (pfile=0x853fd00, reason=LC_ENTER, 
    to_file=0x8563508 "20000503-1.c", file_line=1, sysp=0) at cpplib.c:802
#7  0x080b7ab1 in stack_include_file (pfile=0x853fd00, inc=0x8563550)
    at cppfiles.c:353
#8  0x080b8570 in _cpp_read_file (pfile=0x853fd00, 
    fname=0xbffffc0c "20000503-1.c") at cppfiles.c:761
#9  0x080bac9a in cpp_read_main_file (pfile=0x853fd00, 
    fname=0xbffffc0c "20000503-1.c", table=0x8545fb8) at cppinit.c:942
#10 0x08058cb1 in init_c_lex (filename=0xbffffc0c "20000503-1.c")
    at c-lex.c:149
#11 0x080a2c1a in c_common_init (filename=0xbffffc0c "20000503-1.c")
    at c-common.c:4041
#12 0x080ac25f in c_objc_common_init (filename=0xbffffc0c "20000503-1.c")
    at c-objc-common.c:211
#13 0x080551da in c_init (filename=0xbffffc0c "20000503-1.c") at c-lang.c:91
#14 0x082fc862 in lang_dependent_init (name=0xbffffc0c "20000503-1.c")
    at toplev.c:5067
#15 0x082fcadc in do_compile () at toplev.c:5176
#16 0x082fcb4d in toplev_main (argc=37, argv=0xbffff884) at toplev.c:5209
#17 0x080bdf56 in main (argc=37, argv=0xbffff884) at main.c:35
#18 0x400336cf in __libc_start_main (main=0x80bdf40 <main>, argc=37, 
    ubp_av=0xbffff884, init=0x8049040 <_init>, fini=0x8401bb0 <_fini>, 
    rtld_fini=0x4000aa50 <_dl_fini>, stack_end=0xbffff87c)
    at libc-start.c:129

This is what the yyparse wrapper is for, I think this patch will work
instead...

zw

===================================================================
Index: c-lex.c
--- c-lex.c	2001/12/31 04:13:35	1.163
+++ c-lex.c	2002/01/31 05:47:48
@@ -150,11 +150,14 @@ init_c_lex (filename)
 }
 
 /* A thin wrapper around the real parser that initializes the 
-   integrated preprocessor after debug output has been initialized.  */
+   integrated preprocessor after debug output has been initialized.
+   Also, make sure the start_source_file debug hook gets called for
+   the primary source file.  */
 
 int
 yyparse()
 {
+  (*debug_hooks->start_source_file) (lineno, input_filename);
   cpp_finish_options (parse_in);
 
   return yyparse_1();