From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18275 invoked by alias); 18 Nov 2004 18:14:03 -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 18088 invoked from network); 18 Nov 2004 18:13:27 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 18 Nov 2004 18:13:27 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1CUqmN-0006lU-Mo; Thu, 18 Nov 2004 10:13:11 -0800 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25646-06; Thu, 18 Nov 2004 10:13:11 -0800 (PST) Received: from egret.hq.tensilica.com ([192.168.11.80] ident=[2RzoN8uKq/ZXzjIEyfIXVasRuztcHsbB]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1CUqmN-0006lO-DY; Thu, 18 Nov 2004 10:13:11 -0800 Received: from tensilica.com (IDENT:yjTEmCEj6Lmk3mRwkFo7fpIo2BZs1xc0@egret.hq.tensilica.com [192.168.11.80]) by egret.hq.tensilica.com (8.11.6/8.11.6) with ESMTP id iAIIDAw09787; Thu, 18 Nov 2004 10:13:10 -0800 Message-ID: <419CE636.9090807@tensilica.com> Date: Thu, 18 Nov 2004 18:14:00 -0000 From: Bob Wilson Organization: Tensilica, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: binutils@sources.redhat.com CC: Daniel Jacobowitz , Nick Clifton , Alan Modra 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> <419C69DD.5030106@redhat.com> <20041118115814.GA22378@bubble.modra.org> <20041118142206.GA29928@nevyn.them.org> In-Reply-To: <20041118142206.GA29928@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hq.tensilica.com X-SW-Source: 2004-11/txt/msg00275.txt.bz2 Replying to several messages at once here.... Nick Clifton wrote: > 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: I agree with this. Before submitting the patch, I considered Alan's suggestion that this is a bug in readelf, and regardless of what GAS generates, it does seem that readelf should only look for .debug_line sections that are referenced from .debug_info sections. I'm not going to tackle that change now. After reading the DWARF spec, I think it would be best to fix GAS. I agree with Alan that the current situation is not explicitly prohibited by the DWARF spec, but keeping .debug_line sections tied to .debug_info sections would seem to better follow the spirit of the spec. Alan Modra wrote: > On Thu, Nov 18, 2004 at 09:22:37AM +0000, Nick Clifton wrote: >>> 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. That's irrelevant, though, because the situation in question occurs only when there is no debug line info. dwarf2_finish is currently writing an (empty) .debug_line section even when there is no line number data. The whole point of the patch is to fix that! (Sorry, I guess I didn't make that clear earlier.) Nick Clifton wrote: > As for the patch itself - I am not so sure. It looks to me like there might > be problems when -gdwarf2 is not specified on the command line. ie GAS might > still generate dwarf2 debug sections. I would need to have a look at this > and I am really swamped at the moment. :-( Bob - could you try a few more > tests of your patch please ? Say with various different -gxxx command line > switches specified ? I just tried --gstabs and --gstabs+ for several input files, and I don't see any problems. I think your concern is misplaced, i.e., the patch might not be correct, but it shouldn't cause GAS to generate "extra" dwarf2 debugging output. Look at it this way: the patch removes one of the conditions required for dwarf2_finish to return without doing anything. It can only increase the number of situations where dwarf2_finish does nothing. Daniel Jacobowitz wrote: > 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. Well, I said it was *probably* harmless, and from what you say, I still think that. GDB will ignore the "orphan" .debug_line section, but that's fine -- there's nothing there for GDB to see anyway. > > Is there any reason not to emit a compilation unit, if there isn't one > already, and there is line number data? No, there is no reason not to emit a comp unit in that case, and it will be emitted in that case, both with and without my patch. The patch is intended to address only the case where there is no line number data. I hope that clears things up a bit. As far as I can tell, this shouldn't be a big deal -- it's just tidying up an unusual corner case. --Bob