From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8742 invoked by alias); 18 Nov 2004 14:22:32 -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 8655 invoked from network); 18 Nov 2004 14:22:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 18 Nov 2004 14:22:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CUnAk-0008Jw-VK; Thu, 18 Nov 2004 09:22:07 -0500 Date: Thu, 18 Nov 2004 14:22:00 -0000 From: Daniel Jacobowitz To: Nick Clifton , Bob Wilson , binutils@sources.redhat.com Subject: Re: [PATCH] inconsistent DWARF2 sections generated by --gdwarf2 Message-ID: <20041118142206.GA29928@nevyn.them.org> Mail-Followup-To: Nick Clifton , Bob Wilson , binutils@sources.redhat.com References: <41990311.3060504@tensilica.com> <20041118033117.GD17083@bubble.modra.org> <419C60C8.3020501@redhat.com> <20041118085901.GB21809@bubble.modra.org> <419C69DD.5030106@redhat.com> <20041118115814.GA22378@bubble.modra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041118115814.GA22378@bubble.modra.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00267.txt.bz2 On Thu, Nov 18, 2004 at 10:28:14PM +1030, Alan Modra wrote: > On Thu, Nov 18, 2004 at 09:22:37AM +0000, Nick Clifton wrote: > > >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 ? > > .debug_line by itself gives you a mapping between addresses and source > file line numbers. That might be all a tool needs. Bob's original mail said it was harmless for GDB - but that's not true. GDB will only read line number data associated with some compilation unit. Is there any reason not to emit a compilation unit, if there isn't one already, and there is line number data? -- Daniel Jacobowitz