From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17237 invoked by alias); 17 Apr 2012 15:17:38 -0000 Received: (qmail 17224 invoked by uid 22791); 17 Apr 2012 15:17:36 -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,TW_BJ,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:17:05 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3HFH4qk025526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 11:17:04 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3HFH3SB026466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 11:17:03 -0400 From: Tom Tromey To: Jan Kratochvil Cc: Siddhesh Poyarekar , gdb-patches@sourceware.org Subject: Re: [commit] 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> <878vhuwhrd.fsf@fleche.redhat.com> <20120417145208.GA26552@host2.jankratochvil.net> Date: Tue, 17 Apr 2012 15:18:00 -0000 In-Reply-To: <20120417145208.GA26552@host2.jankratochvil.net> (Jan Kratochvil's message of "Tue, 17 Apr 2012 16:52:08 +0200") Message-ID: <87vckyv15c.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/msg00488.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> I did not think such optimization is worth the work. But I am Jan> aware you and Google did various work on the memory footprint Jan> reduction. From my point of view 32-bit GDB without Jan> --enable-64-bit-bfd either does not exist (anywhere in Fedora) or Jan> it is some very special build. Yeah. Jan> The problem is LOC_CONST_BYTES needs special handling and current Jan> accessor of SYMBOL_VALUE and its other union-accessors like Jan> SYMBOL_VALUE_BYTES cannot be easily protected in any way without Jan> either ({ forbidden GCC extensions }) or ->C++_accessor() so I am Jan> reluctant to break existing code blindly expecting LOC_CONST Jan> without checking it and using SYMBOL_VALUE. If that code exists it has to be a crash waiting to happen. Jan> Also I think if 40 vs. 44 minimal_symbol size is of any concern we Jan> should do some real fixes such as lazy objfiles reading or lazy Jan> minimal_symbol expansion. partial_symbol memory cost seems to be Jan> fixed by .gdb_index already, isn't it? I guess so, but it isn't universally used (and really isn't that good for all uses). And as you've pointed out, idb does fine without needing this. Jan> Full symbol tables get expanded in some cases but that should also Jan> be fixed in a real way (such as some -complation expands them Jan> while it could not have to) instead of saving 4 out of 44 bytes. The completion thing is an interesting idea. It does seem pointless to expand symtabs in this case. I wonder if there is a rationale. Tom