From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20515 invoked by alias); 25 Apr 2003 16:38:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20508 invoked from network); 25 Apr 2003 16:38:04 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 25 Apr 2003 16:38:04 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h3PGbvT10811; Fri, 25 Apr 2003 09:37:57 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: Elena Zannoni , Jim Blandy , gdb Subject: Re: [rfc] struct dictionary References: <3EA89AB3.6050403@redhat.com> <3EA954D7.2070207@redhat.com> From: David Carlton Date: Fri, 25 Apr 2003 16:38:00 -0000 In-Reply-To: <3EA954D7.2070207@redhat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00316.txt.bz2 On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney said: > Ok, humor me ... > http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even > build these data structures during symbol reading? It takes time > and space, yet is probably never used. Why not on-demand build this > dictionary specialized for the block? That sounds great to me if we can get it to work. It's certainly another reason to try to get the symbol lookup stuff abstracted behind an opaque interface: it makes lazy loading of data a lot easier. About the mdebugread stuff: personally, I don't care about it in the slightest, so I'm happy for its performance to degrade, and it seems little-enough used that a 2x degradation is perfectly acceptable. After all, if anybody really cares about it, there's an easy fix: buildsym-ify it, so that it uses the same mechanisms everybody else does. Having said that, I've already done the work on my branch to convert it to an efficient dictionary mechanism (using a combination of hashed and unsorted linear representations); it really wasn't all that much work. As far as special cases go, I'm much more worried about the Java one: the mechanism that Java uses for dynamically loaded classes is extremely fragile, and only works through a chain of unintentional coincidences. Basically, it creates this block that is linear, isn't sorted, but yet satisfies BLOCK_SHOULD_SORT, but there's special-case code in all the symbol lookup functions to look through Java blocks linearly instead of using sorting, where the stated reasons for doing so are, I think, not correct, and where this one block for which it actually _is_ necessary is never mentioned. Also, I think that C++ could benefit from having a few special-purpose blocks like Java does, because C++ classes and namespaces aren't naturally tied to a single file. David Carlton carlton@math.stanford.edu