From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24831 invoked by alias); 17 Apr 2012 15:32:24 -0000 Received: (qmail 24821 invoked by uid 22791); 17 Apr 2012 15:32:23 -0000 X-SWARE-Spam-Status: No, hits=-6.3 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 15:32:07 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3HFW6wP005593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 11:32:06 -0400 Received: from host2.jankratochvil.net (ovpn-116-17.ams2.redhat.com [10.36.116.17]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3HFW2TT018619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 11:32:05 -0400 Date: Tue, 17 Apr 2012 15:42:00 -0000 From: Jan Kratochvil To: Tom Tromey 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] Message-ID: <20120417153202.GB27888@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> <20120417143219.GA25827@host2.jankratochvil.net> <87zkaav1i4.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zkaav1i4.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/msg00491.txt.bz2 On Tue, 17 Apr 2012 17:09:23 +0200, Tom Tromey wrote: > 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). Personally I still do not think we should care too much about one 'struct symbol'. There is more a problem we create too many 'struct symbol' which are never used. > 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. I think this would be a win contrary to other disadvantages; I have sure no technical arguments for that, other than accessing memory outside of the CPU cache is terribly slow and several more bytes are worth the acceleration. > 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? BTW without making some big decisions one should do some more serious test of idb, or at least to be tested by a second person, I did just a quick test myself (that GDB is 800%-times slower even with .gdb_index), I could make some mistakes and I even no longer remember all the details how I specifically did the test. Thanks, Jan