Re: GDB 7.7 crashes on LTO-built executable

[Tom Tromey <tromey at redhat dot com>]

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

Yes, I think so, at least if by "single-objfile" you mean "single .o
file", and not the gdb meaning of the term.

What I find strange is that subfiles are created with a NULL debugformat
and then, at least for the DWARF reader, nothing ever seems to change
this.

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

It's complicated :)  Basically a number of things can change
current_source_symtab.  You can search for assignments to it in source.c.
But I think the problem must be on the producer side.

>> 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 :)

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

I don't know, but all I mean is that if gdb is creating a symtab, then
there is some code reading some kind of debuginfo to create said symtab;
and this code must necessarily be specific to some debug format and
could therefore record it.

One idea would be that subfiles could perhaps inherit the debug format
from their parent files; or this code could at includers for the info;
if that is in fact the issue.

Tom