From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25937 invoked by alias); 17 Apr 2012 15:52:44 -0000 Received: (qmail 25927 invoked by uid 22791); 17 Apr 2012 15:52:43 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Tue, 17 Apr 2012 15:52:25 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3HFqNfl015759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 11:52:24 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3HF9NpJ021806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 11:09:24 -0400 From: Tom Tromey To: Jan Kratochvil Cc: Siddhesh Poyarekar , gdb-patches@sourceware.org Subject: Re: [patch] Support 64-bit constants/enums on 32-bit host [Re: [PATCH] Allow 64-bit enum values] References: <20120220132724.GB4753@spoyarek.pnq.redhat.com> <87d397syts.fsf@fleche.redhat.com> <20120229135148.GA32128@spoyarek.pnq.redhat.com> <20120301224428.GA30631@host2.jankratochvil.net> <20120305063542.GA30196@spoyarek.pnq.redhat.com> <20120305080512.GA12311@host2.jankratochvil.net> <20120321100630.GA14496@spoyarek.pnq.redhat.com> <20120417130833.GB15356@host2.jankratochvil.net> <20120417143219.GA25827@host2.jankratochvil.net> Date: Tue, 17 Apr 2012 15:59:00 -0000 In-Reply-To: <20120417143219.GA25827@host2.jankratochvil.net> (Jan Kratochvil's message of "Tue, 17 Apr 2012 16:32:19 +0200") Message-ID: <87zkaav1i4.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-04/txt/msg00494.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> The expansion is for partial_symbol -> symbol which may have some Jan> sense as it saves almost 50% of space, both represent one DWARF Jan> symbol. I looked into this recently while thinking about lazy CU expansion. The main difficulty is that you need a way to associate the psymbol with the full symbol. Right now there is no way at all to do this. In DWARF terms this means storing the DIE offset in the psymbol. But, this is a problem for two reasons. First, the bcache really helps with the size of psymbols, but if you store the DIE offset in the psymbol itself, it will defeat the purpose of the bcache. Second, of course, adding anything to psymbols makes them larger; and since most psymbols are not in fact expanded, the overall effect may be a lose. This latter consideration is why I am not yet persuaded that the change is worth doing in isolation. I think it could be done by storing the DIE offset in the psymbol lists, instead of in the psymbol itself. This could be a fairly localized change (even optional, per-objfile) in psymtab.c. Then, you could have two variants of struct symbol -- one that has a pointer to its corresponding psymbol, and one that includes the psymbol. This would mean updating all the accessors to check a bit in the symbol. Due to the way that struct symbol is packed, I think this would only save sizeof(general_symbol_info) - sizeof(void*) bytes (32 bytes per symbol on x86-64). This idea would make lazy CU expansion a bit faster, because you wouldn't have to re-scan the DIEs to make the symbol table. Then the idea would be to make symbols whose types and (for functions) blocks are uninitialized, then change SYMBOL_TYPE et al to read and interpret the necessary DIEs on demand. I think this isn't extremely hard, but the tradeoffs are still not entirely clear to me, and as you pointed out on irc, the result will still probably be slower than idb -- IOW, we're doing something really wrong, so why not start by finding that? Tom