From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 475 invoked by alias); 12 Oct 2009 20:43:15 -0000 Received: (qmail 464 invoked by uid 22791); 12 Oct 2009 20:43:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 12 Oct 2009 20:43:08 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n9CKh6TM029186 for ; Mon, 12 Oct 2009 16:43:06 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n9CKh6df030296; Mon, 12 Oct 2009 16:43:06 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n9CKh4Wf000689; Mon, 12 Oct 2009 16:43:05 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 8390537828F; Mon, 12 Oct 2009 14:43:04 -0600 (MDT) From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch] Support DW_OP_call2 and DW_OP_call4 (PR 10640) References: <20090920123647.GA30021@host0.dyn.jankratochvil.net> Reply-To: tromey@redhat.com Date: Mon, 12 Oct 2009 20:43:00 -0000 In-Reply-To: <20090920123647.GA30021@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Sun, 20 Sep 2009 14:36:47 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00248.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> as GCC discusses its use in PR41343 the patch implements it for GDB. Thanks. Jan> It has some new overhead due to symbol_hash for all symbol DIEs. Jan> Did not measure it but I am not aware much how it could be avoided Jan> as GDB does not parse the DWARF blocks while reading them in. 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. I thought of one way to reduce the overhead a bit, but it is fairly gross. We could have dwarf2read.c make symbols like: struct dwarf_symbol { struct symbol base; int offset; }; Then, where it matters, "downcast" from symbol to dwarf_symbol and find the offset. symbol_hash would just directly hold dwarf_symbols, no need for struct dwarf2_offset_and_symbol. This would save a pointer per symbol. That said, I probably would not bother with this until we know that space is an issue. I know that symtab.h claims that symbol size is a problem, but I am not sure that this is really true -- I suspect it is only the case with -readnow, which most people don't use. The ugliness here is that it assumes that no other part of gdb cares about the size of a symbol. This is probably true but also a fragile assumption. Jan> 2009-09-20 Jan Kratochvil Jan> Fix PR 10640. [...] Ok. Tom