GDB 7.7 crashes on LTO-built executable

GDB 7.7 crashes on LTO-built executable

[Eli Zaretskii]

I compiled a simple test program with -flto using MinGW GCC 4.7.2, and
tried to debug it with GDB 7.7.  However, "info source" crashed with
SIGSEGV.  It turns out that source_info was trying to output this
line:

  printf_filtered (_("Compiled with %s debugging format.\n"), s->debugformat);

and s->debugformat was a NULL pointer.

Looking around, it sounds like when GDB iterates over objfiles, it
gets a weird file name, something like $TMPDIR/ccN8FPgQ.ltrans0.o,
instead of the expected name of the (single) object file name for this
program.  The real objfile then ends up with a NULL pointer instead of
its debugformat field.

Is this expected with LTO programs?  Is there a better way than saying
"unknown" when s->debugformat is NULL?

TIA

Re: GDB 7.7 crashes on LTO-built executable

[Eli Zaretskii]

> Date: Wed, 12 Feb 2014 19:37:02 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Is there a better way than saying "unknown" when s->debugformat is
> NULL?

A better way to fix the crash, I mean.

Re: GDB 7.7 crashes on LTO-built executable

[Tom Tromey]

>> Is there a better way than saying "unknown" when s->debugformat is
>> NULL?

Eli> A better way to fix the crash, I mean.

I looked a tiny bit.

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.

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

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

Tom

Re: 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.

Re: GDB 7.7 crashes on LTO-built executable

[Tom Tromey]

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

Re: GDB 7.7 crashes on LTO-built executable

[Eli Zaretskii]

Some more info, obtained by setting various debug options: With a
non-LTO build of the same program, GDB displays this after it finishes
reading the symbols and expanding the symtabs:

  Created primary symtab 0x2125880 for tchmod.c
  ...
  qf->lookup_symbol (...) = tchmod.c

(tchmod.c is the source file of this program.)

But when I do the same with the LTO-compiled executable, the last
message is:

  Created primary symtab 0x21172d0 for C:\Users\eliz\AppData\Local\Temp\ccN8FPgQ.ltrans0.o.
  ...
  qf->lookup_symbol (...) = C:\Users\eliz\AppData\Local\Temp\ccN8FPgQ.ltrans0.o

Re: 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 13:05:33 -0700
> 
> 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.

Yes, I meant a single-source file program, and the objfile created
from that source file.

> 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.

Yes, the DWARF 2 debuginfo _is_ recorded, but for a file name that has
nothing to do with the name of the source file from which the program
was compiled.

Re: GDB 7.7 crashes on LTO-built executable

[Eli Zaretskii]

> Date: Wed, 12 Feb 2014 22:11:19 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org
> 
> Yes, the DWARF 2 debuginfo _is_ recorded, but for a file name that has
> nothing to do with the name of the source file from which the program
> was compiled.

This happens in read_file_scope, which is called from process_die.
read_file_scope calls find_file_and_directory, which uses DW_AT_name
attribute to get the file name.  And that file name turns out to be
$TMPDIR/ccN8FPgQ.ltrans0.o instead of the expected foo.c, which is the
source file I compiled.  So the DWARF 2 debug info is set for that
temporary file name, instead of the source file.

The call to process_die happens as part of set_initial_language, which
looks for a symbol "main".

The name of the source file is available in the psymtab that is
accessible from the die (via the objfile struct).  the question is
what should be the conditions under which we need to look there.
E.g., can the fact that DW_AT_name returns a name of an object file be
that condition?