From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29206 invoked by alias); 17 Apr 2012 14:33:09 -0000 Received: (qmail 29197 invoked by uid 22791); 17 Apr 2012 14:33:08 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,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 14:32:56 +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 q3HEWuDj001553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 10:32:56 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3HEWs6O032137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 10:32:55 -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> Date: Tue, 17 Apr 2012 14:33:00 -0000 In-Reply-To: <20120417130833.GB15356@host2.jankratochvil.net> (Jan Kratochvil's message of "Tue, 17 Apr 2012 15:08:33 +0200") Message-ID: <878vhuwhrd.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/msg00480.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> BTW why we have minimal_symbol and expand it later when it has "the same" Jan> size? Just expanding the types would have the same effect. We discussed on irc, Jan was confused :) Jan> In all other configuration it has no memory footprint change. Jan> - /* The fact that this is a long not a LONGEST mainly limits the Jan> - range of a LOC_CONST. Since LOC_CONST_BYTES exists, I'm not Jan> - sure that is a big deal. */ Jan> - long ivalue; Jan> + LONGEST ivalue; Jan> Going to check it in, probably today, if there are any concerns about those Jan> 4 added bytes. I personally am not particularly concerned. 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? Tom