From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10079 invoked by alias); 1 Dec 2009 19:14:00 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 10068 invoked by uid 22791); 1 Dec 2009 19:13:59 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org From: Tom Tromey To: Cary Coutant Cc: Dodji Seketeli , "GDB\/Archer list" Subject: Re: [RFC] Proposal for a new DWARF name index section References: <4A7FE28D.4050901@redhat.com> <4A8D8868.3010302@redhat.com> Reply-To: Tom Tromey Date: Tue, 01 Dec 2009 19:14:00 -0000 In-Reply-To: (Tom Tromey's message of "Fri, 20 Nov 2009 10:24:38 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2009-q4/txt/msg00068.txt.bz2 >>> As a follow up to this proposal, I have opened an enhancement request in >>> the gcc bugzilla at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130 . Cary> It seems to me that the .debug_pubnames/pubtypes/aranges sections were Cary> created specifically so that the debugger could have fast access Cary> without having to pre-read all the debug info, so the idea of creating Cary> a new section rather than fix the one we already have is questionable. Tom> Yes, I agree it would be ideal not to do this. I still haven't implemented pubtypes/pubnames reading, but I did run across a couple of other problems not solved by those. I'd like to get people's reactions. To reiterate a little, my goal here is maximal performance. Ideally, the initial read would be very fast -- fast than the user can perceive. This is probably not achievable, but we can get close. The biggest fixable performance problem in the current reader is actually computing the hash codes for the strings from the .debug_gnu_index section. So, I've been thinking about putting the hash code directly into the section. The other problem I've noticed is name canonicalization. This past year, we changed gdb to canonicalize names in its symbol tables, and to canonicalize user input before doing lookups. This lets gdb return the right answer even when the order of modifiers varies. This change slowed down DWARF reading, and it occurred to me that it would also substantially slow down index reading. So, I would also like to change the .debug_gnu_index spec to specify how names are to be canonicalized. The hash code idea seems a little weird to me, but the name canonicalization problem seems important to solve. Tom