From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16862 invoked by alias); 12 Feb 2014 20:05:39 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 16852 invoked by uid 89); 12 Feb 2014 20:05:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2014 20:05:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1CK5Ynw022322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Feb 2014 15:05:35 -0500 Received: from barimba (ovpn-113-148.phx2.redhat.com [10.3.113.148]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1CK5XEo023272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 12 Feb 2014 15:05:33 -0500 From: Tom Tromey To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: GDB 7.7 crashes on LTO-built executable References: <83lhxgs05d.fsf@gnu.org> <83ioskrznz.fsf@gnu.org> <87ob2ct9ua.fsf@fleche.redhat.com> <83ha84ruai.fsf@gnu.org> Date: Wed, 12 Feb 2014 20:05:00 -0000 In-Reply-To: <83ha84ruai.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 12 Feb 2014 21:43:33 +0200") Message-ID: <87d2ist7ua.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-02/txt/msg00434.txt.bz2 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