From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2282 invoked by alias); 22 Nov 2009 20:22:44 -0000 Received: (qmail 2273 invoked by uid 22791); 22 Nov 2009 20:22:43 -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; Sun, 22 Nov 2009 20:21:51 +0000 Received: from bromo.med.uc.edu (localhost.localdomain [127.0.0.1]) by bromo.med.uc.edu (Postfix) with ESMTP id 24630B0054; Sun, 22 Nov 2009 15:21:49 -0500 (EST) Received: (from howarth@localhost) by bromo.med.uc.edu (8.14.3/8.14.3/Submit) id nAMKLmSA012615; Sun, 22 Nov 2009 15:21:48 -0500 Date: Mon, 23 Nov 2009 14:17:00 -0000 From: Jack Howarth To: Jan Kratochvil Cc: gdb@sourceware.org Subject: Re: check for valid location of zero length dwarf block forms? Message-ID: <20091122202148.GA12580@bromo.med.uc.edu> References: <20091121034258.GA6166@bromo.med.uc.edu> <20091122110259.GA9268@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091122110259.GA9268@host0.dyn.jankratochvil.net> 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/msg00174.txt.bz2 On Sun, Nov 22, 2009 at 12:02:59PM +0100, Jan Kratochvil wrote: > On Sat, 21 Nov 2009 04:42:58 +0100, Jack Howarth wrote: > > ...as dwarf debug info containing an AT_location with > > any block form having a zero length. > > It is correct and equivalent according to the DWARF spec. and for gcc it seems > to differentiate a case of known optimized-out value (=empty) vs. the case of > gcc failed to describe the variable location (=missing). > dwarflint: DW_AT_location being empty vs. missing check > https://fedorahosted.org/pipermail/elfutils-devel/2009-March/000179.html > https://fedorahosted.org/pipermail/elfutils-devel/2009-March/000180.html > > > Regards, > Jan Jan, Is this being done in the following code from dwarf2out.c? /* Resolve DW_OP_addr and DW_AT_const_value CONST_STRING arguments to an address in .rodata section if the string literal is emitted there, or remove the containing location list or replace DW_AT_const_value with DW_AT_location and empty location expression, if it isn't found in .rodata. Similarly for SYMBOL_REFs, keep only those that refer to something that has been emitted in the current CU. */ static void resolve_addr (dw_die_ref die) { dw_die_ref c; dw_attr_ref a; dw_loc_list_ref curr; unsigned ix; for (ix = 0; VEC_iterate (dw_attr_node, die->die_attr, ix, a); ix++) switch (AT_class (a)) { case dw_val_class_loc_list: for (curr = AT_loc_list (a); curr != NULL; curr = curr->dw_loc_next) if (!resolve_addr_in_expr (curr->expr)) curr->expr = NULL; break; case dw_val_class_loc: if (!resolve_addr_in_expr (AT_loc (a))) a->dw_attr_val.v.val_loc = NULL; break; case dw_val_class_addr: if (a->dw_attr == DW_AT_const_value && resolve_one_addr (&a->dw_attr_val.v.val_addr, NULL)) { a->dw_attr = DW_AT_location; a->dw_attr_val.val_class = dw_val_class_loc; a->dw_attr_val.v.val_loc = NULL; } break; default: break; } FOR_EACH_CHILD (die, c, resolve_addr (c)); } The problem we have on darwin is that, while Apple will likely fix dsymutils for Xcode 3.2 (Snow Leopard), it probably will remain broken for Tiger and Leopard's devtools. So it would be helpful to find some way to suppress this offending dwarf code on darwin in the cases were the variable has a valid location but is zero length or doesn't have a location. Otherwise we won't be able to generate dSYMs with dsymutil on those releases of Mac OS X with gcc 4.5 and later. Jack