From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1992 invoked by alias); 17 Apr 2012 14:52:46 -0000 Received: (qmail 1960 invoked by uid 22791); 17 Apr 2012 14:52:44 -0000 X-SWARE-Spam-Status: No, hits=-5.5 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 14:52:14 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3HEqDS0026253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 10:52:13 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3HEq9PE008184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 10:52:12 -0400 Date: Tue, 17 Apr 2012 14:55:00 -0000 From: Jan Kratochvil To: Tom Tromey 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] Message-ID: <20120417145208.GA26552@host2.jankratochvil.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878vhuwhrd.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-04/txt/msg00484.txt.bz2 On Tue, 17 Apr 2012 16:32:54 +0200, Tom Tromey wrote: > But the comment that you removed seems to indicate another possible > approach -- just use LOC_CONST_BYTES for these enum values. > > Would that not work for some reason? > > I am thinking that presumably people who build a 32-bit gdb without > --enable-64-bit-bfd are interested in the smallest memory footprint. > Also presumably they are not likely to be debugging many 64 bit > processes or perhaps even using enums with values requiring 64 bits; > certainly those would be relatively rare cases. So, if LOC_CONST_BYTES > works, it would be an overall memory savings. > > What do you think of this? I did not think such optimization is worth the work. But I am aware you and Google did various work on the memory footprint reduction. From my point of view 32-bit GDB without --enable-64-bit-bfd either does not exist (anywhere in Fedora) or it is some very special build. The problem is LOC_CONST_BYTES needs special handling and current accessor of SYMBOL_VALUE and its other union-accessors like SYMBOL_VALUE_BYTES cannot be easily protected in any way without either ({ forbidden GCC extensions }) or ->C++_accessor() so I am reluctant to break existing code blindly expecting LOC_CONST without checking it and using SYMBOL_VALUE. Also I think if 40 vs. 44 minimal_symbol size is of any concern we should do some real fixes such as lazy objfiles reading or lazy minimal_symbol expansion. partial_symbol memory cost seems to be fixed by .gdb_index already, isn't it? Full symbol tables get expanded in some cases but that should also be fixed in a real way (such as some -complation expands them while it could not have to) instead of saving 4 out of 44 bytes. Thanks, Jan