From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10682 invoked by alias); 21 Nov 2009 03:43:51 -0000 Received: (qmail 10674 invoked by uid 22791); 21 Nov 2009 03:43:50 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from bromo.med.uc.edu (HELO bromo.med.uc.edu) (129.137.3.146) by sourceware.org (qpsmtpd/0.43rc1) with SMTP; Sat, 21 Nov 2009 03:43:01 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id EB58DB0054 for ; Fri, 20 Nov 2009 22:42:58 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nAL3gwur006266 for gdb@sourceware.org; Fri, 20 Nov 2009 22:42:58 -0500 Date: Sun, 22 Nov 2009 17:04:00 -0000 From: Jack Howarth To: gdb@sourceware.org Subject: check for valid location of zero length dwarf block forms? Message-ID: <20091121034258.GA6166@bromo.med.uc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-11/txt/msg00169.txt.bz2 Since the var-tracking-association code merge into gcc trunk, we have had issues with Apple's dsymutil program crashing on the code generated by the FSF gcc trunk compiler... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473 Apple's dsymutil maintainer analyzed this issue... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c27 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c29 ...as dwarf debug info containing an AT_location with any block form having a zero length. The question is if these emitted dwarf codes are accidental errors. Apple believes that if the variable doesn't have a location, the DW_AT_location attribute shouldn't be emitted. Also, if the variable does have a valid location, then the length of zero is likely a bug in dwarf2out.c. It might be worthwhile for the gdb developers to look into this issue since there might be either unnecessary dwarf output or incorrect dwarf output that binutils doesn't recognize as such. Thanks in advance for any comments. Jack