Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: GDB 7.7 crashes on LTO-built executable
Date: Wed, 12 Feb 2014 20:05:00 -0000	[thread overview]
Message-ID: <87d2ist7ua.fsf@fleche.redhat.com> (raw)
In-Reply-To: <83ha84ruai.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 12 Feb	2014 21:43:33 +0200")

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


  reply	other threads:[~2014-02-12 20:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-12 17:37 Eli Zaretskii
2014-02-12 17:47 ` Eli Zaretskii
2014-02-12 19:22   ` Tom Tromey
2014-02-12 19:43     ` Eli Zaretskii
2014-02-12 20:05       ` Tom Tromey [this message]
2014-02-12 20:11         ` Eli Zaretskii
2014-02-15 16:58           ` Eli Zaretskii
2014-02-12 20:08       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d2ist7ua.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox