From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3864 invoked by alias); 18 Nov 2004 09:18:37 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 3852 invoked from network); 18 Nov 2004 09:18:34 -0000 Received: from unknown (HELO relay3.mail.uk.clara.net) (80.168.70.143) by sourceware.org with SMTP; 18 Nov 2004 09:18:34 -0000 Received: from adsl-2-solo-172-135.claranet.co.uk ([80.168.172.135] helo=[172.31.0.98]) by relay3.mail.uk.clara.net with esmtp (Exim 4.34) id 1CUiQy-0008E0-E5; Thu, 18 Nov 2004 09:18:32 +0000 Message-ID: <419C69DD.5030106@redhat.com> Date: Thu, 18 Nov 2004 09:18:00 -0000 From: Nick Clifton User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) MIME-Version: 1.0 To: Alan Modra CC: Bob Wilson , binutils@sources.redhat.com Subject: Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2 References: <41990311.3060504@tensilica.com> <20041118033117.GD17083@bubble.modra.org> <419C60C8.3020501@redhat.com> <20041118085901.GB21809@bubble.modra.org> In-Reply-To: <20041118085901.GB21809@bubble.modra.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00264.txt.bz2 Hi Alan, >>I do not think so - the DWARF standard does specify that there there >>should be a correspondence between the compilation units in the >>.debug_info section and the compilation units in the .debug_line section: >> >> From "Section 6.2 Line number Information": >> >> As mentioned in Section 3.1.1, the line number information >> generated for a compilation unit is represented in the >> .debug_line section of an object file and is referenced by >> corresponding compilation unit debugging information entry >> in the .debug_info section. > But that's the other way around, .debug_info references .debug_line. In > this case we have .debug_line with no .debug_info, which should be OK. Does that make sense though ? A .debug_line compilation unit which does not correspond to any .debug_info compilation unit ? What lines would it be describing ? Why would these lines exist without any debug info ? Cheers Nick