GDB 7.7 crashes on LTO-built executable

[Eli Zaretskii]

> From: Tom Tromey <tromey@redhat.com>
> Cc: gdb-patches@sourceware.org
> Date: Wed, 12 Feb 2014 12:22:21 -0700
> 
> I don't know what code path hits this, but basically something is not
> calling record_debugformat when it ought to.  So one way to fix the bug
> would be to track down what this is.  I would probably start by finding
> where the symtab in question was allocated.

OK, I'll look around some more.

> The current design seems fragile in that it requires sprinkling these
> calls to record_debugformat all around.

That's true (I see gobs of calls to that function), but all but one of
these calls are from coff_start_symtab, and the argument 'format' is
NULL, as expected.  There's only one call to record_debugformat from
the DWARF 2 reader, the one I described in my original message.  This
is expected in a single-objfile program, right?

Assuming my guess is correct, and the reason for the problem is that
the only objfile GDB sees has its name set to some temporary file
rather than the source file of the program, where's the code which
tries to match the current source file with the known objfiles?  I
assume that when I type "info source", GDB looks for the information
about the current source file -- where is the code which does that?

> I did find this comment in buildsym.c:
> 
> 	  /* Save the debug format string (if any) in the symtab.  */
> 	  symtab->debugformat = subfile->debugformat;
> 
> And it does seem that nothing tries to ensure that a subfile's
> debugformat is set.  So perhaps fixing it at the printf site is fine; or
> alternatively changing the field's initialization in start_subfile.
> Though it seems better to try to fix the value properly; since "unknown"
> can't ever really be correct -- it it's unknown one wonders how gdb
> could have read it :)

I think GDB really doesn't know it have read the DWARF 2 info in this
case.  I think it uses the COFF information (which includes line
table, right?).

Thanks.