From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16188 invoked by alias); 4 May 2006 09:07:22 -0000 Received: (qmail 16074 invoked by uid 22791); 4 May 2006 09:07:20 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 May 2006 09:06:44 +0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1FbZnC-0005HB-SQ; Thu, 04 May 2006 02:06:39 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19603-06; Thu, 4 May 2006 02:06:38 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.10.147]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1FbZmy-0005Gl-1W; Thu, 04 May 2006 02:06:28 -0700 Message-ID: <4459C400.6040709@tensilica.com> Date: Thu, 04 May 2006 09:07:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Daniel Jacobowitz CC: GDB List Subject: Re: Source info in discontiguous hand asm files References: <44595771.1070907@tensilica.com> <20060504015948.GA19834@nevyn.them.org> In-Reply-To: <20060504015948.GA19834@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00017.txt.bz2 Daniel Jacobowitz wrote: >On Wed, May 03, 2006 at 06:22:57PM -0700, Ross Morley wrote: > > >>Hello, >> >>gdb 6.1, as 2.15.92.0.2, gcc 3.4.2 per FC3 distro. >> >> > >All of these are fairly old versions. Have you looked at the generated >debug information? Is it correct, or not? > > Yes, it is correct, though not as extensive as it could be. In the case where there are multiple ranges of text in a compilation unit, DA_AT_{low,high}_pc is omitted from the CU per DWARF spec. Where there is only one range of text, those are present and correct. The assembler doesn't add function-specific info. There is info in the aranges table to associate the ranges with the compilation unit, so a scan of that table could provide it. I'm reluctant to say much about my incomplete analysis, given my lack of familiarity with GDB handling of symbols and debug info. However, at risk of having missed something, here's what I found. I've stepped through the lookup of the symtab and there's no source file info associated with the symbol. To find out why, I've stepped through the reading of the dwarf info. The relevant code is in dwarf2read.c, function dwarf2_build_psymtabs_hard(). The psymtab for the CU ends up not having its 'textlow' and 'texthigh' set, so they remain 0x0 after the DWARF is read. I don't know enough about the process of building the symtabs to be sure, but I suspect this leads to the lack of source file info associated with the symbols in this CU. I've looked at GDB 6.4 sources and it's the same, so I'd be surprised if you can't reproduce this at top of trunk. The test case is very easy to try if you have a top of trunk build. >>The DWARF .debug_aranges section seems to have enough information >>to deal with this, but GDB doesn't use it. >> >> > >I'm not sure how .debug_aranges comes into this. That's used to >describe the range of the compilation unit DIEs and shouldn't affect >.debug_line. > > Somehow the debug line info doesn't make it into the symbol table, perhaps because the psymtab is not associated with the correct range (again, I'm guessing, not being familiar with this stuff). There is other DWARF info that the assembler could include but doesn't (compiler-generated DWARF does, so this problem doesn't show there). However a fix there would require end users to edit their source, which is why I'm being asked to solve it in GDB. There is enough info in the DWARF to determine which source file addresses in these ranges belong to, so the expectation is that GDB should be able to figure it out. If that's not the case, then the assembler has a problem. Thanks for any insight. Ross