From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 780 invoked by alias); 12 Oct 2009 21:08:51 -0000 Received: (qmail 770 invoked by uid 22791); 12 Oct 2009 21:08:51 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Oct 2009 21:08:46 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id BF2B410CF8; Mon, 12 Oct 2009 21:10:32 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 9F26710B94; Mon, 12 Oct 2009 21:10:32 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MxS8K-0005Tz-9O; Mon, 12 Oct 2009 17:08:44 -0400 Date: Mon, 12 Oct 2009 21:08:00 -0000 From: Daniel Jacobowitz To: Tom Tromey Cc: Jan Kratochvil , gdb-patches@sourceware.org Subject: Re: [patch] Support DW_OP_call2 and DW_OP_call4 (PR 10640) Message-ID: <20091012210844.GA20340@caradoc.them.org> Mail-Followup-To: Tom Tromey , Jan Kratochvil , gdb-patches@sourceware.org References: <20090920123647.GA30021@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00251.txt.bz2 On Mon, Oct 12, 2009 at 02:43:04PM -0600, Tom Tromey wrote: > Yeah, I could not think of a way to avoid it either. I think parsing > the DWARF while reading would be worse than what you have now, because > (IIUC) it would negatively impact performance. This is all part of inter-CU references. You can't (always) parse it as you read it in; there can be dependency loops. I'm confused as to why the "struct symbol" comes into this though. We're just using it to look up its DWARF location again. Can we do this directly off the target DIE? We don't free up the loaded .debug_info (partly to support DW_FORM_string). And we have infrastructure to load a given CU's dies whenever we need them. IIUC this would require a different implementation of the baton for DIEs without a symbol. -- Daniel Jacobowitz CodeSourcery