From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1377 invoked by alias); 12 Feb 2014 19:43:46 -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 1366 invoked by uid 89); 12 Feb 2014 19:43:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout23.012.net.il Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Feb 2014 19:43:44 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N0W00E00EOSVF00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Wed, 12 Feb 2014 21:43:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N0W00ED7ESTSF60@a-mtaout23.012.net.il>; Wed, 12 Feb 2014 21:43:41 +0200 (IST) Date: Wed, 12 Feb 2014 19:43:00 -0000 From: Eli Zaretskii Subject: Re: GDB 7.7 crashes on LTO-built executable In-reply-to: <87ob2ct9ua.fsf@fleche.redhat.com> To: Tom Tromey Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ha84ruai.fsf@gnu.org> References: <83lhxgs05d.fsf@gnu.org> <83ioskrznz.fsf@gnu.org> <87ob2ct9ua.fsf@fleche.redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00432.txt.bz2 > From: Tom Tromey > 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.