From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23900 invoked by alias); 17 Apr 2012 15:48:53 -0000 Received: (qmail 23888 invoked by uid 22791); 17 Apr 2012 15:48:52 -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 15:48:36 +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 q3HFmaBK001766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Apr 2012 11:48:36 -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 q3HFmYFU010709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 11:48:35 -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> <87zkaav1i4.fsf@fleche.redhat.com> <20120417153202.GB27888@host2.jankratochvil.net> Date: Tue, 17 Apr 2012 15:52:00 -0000 In-Reply-To: <20120417153202.GB27888@host2.jankratochvil.net> (Jan Kratochvil's message of "Tue, 17 Apr 2012 17:32:02 +0200") Message-ID: <87k41euzot.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/msg00493.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Tom> This idea would make lazy CU expansion a bit faster, because you Tom> wouldn't have to re-scan the DIEs to make the symbol table. Jan> I think this would be a win contrary to other disadvantages; I have Jan> sure no technical arguments for that, other than accessing memory Jan> outside of the CPU cache is terribly slow and several more bytes Jan> are worth the acceleration. Yeah, that makes sense to me. Not scanning the .debug_info again seems like it could really win. Tom> and as you pointed out on irc, the result will Tom> still probably be slower than idb -- IOW, we're doing something really Tom> wrong, so why not start by finding that? Jan> BTW without making some big decisions one should do some more Jan> serious test of idb, or at least to be tested by a second person, I Jan> did just a quick test myself (that GDB is 800%-times slower even Jan> with .gdb_index), I could make some mistakes and I even no longer Jan> remember all the details how I specifically did the test. Yeah, I'd like to get to it eventually. One nice thing about the psymtab->symtab thought experiment is that I've convinced myself that the problem, whatever it may be, can at least be isolated down to dwarf2read.c. So, I feel it must be fixable without excessive work on gdb. Tom