From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22964 invoked by alias); 19 Sep 2002 13:29:35 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22945 invoked from network); 19 Sep 2002 13:29:34 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Sep 2002 13:29:34 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17s2Iw-0007Sc-00; Thu, 19 Sep 2002 09:29:18 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17s1Mx-0004Q8-00; Thu, 19 Sep 2002 09:29:23 -0400 Date: Thu, 19 Sep 2002 06:29:00 -0000 From: Daniel Jacobowitz To: Hilfinger@otisco.mckusick.com Cc: carlton@math.stanford.edu, gdb-patches@sources.redhat.com, aidan@velvet.net, jimb@redhat.com, ezannoni@redhat.com Subject: Re: [RFA] delete BLOCK_SHOULD_SORT Message-ID: <20020919132923.GA16924@nevyn.them.org> Mail-Followup-To: Hilfinger@otisco.mckusick.com, carlton@math.stanford.edu, gdb-patches@sources.redhat.com, aidan@velvet.net, jimb@redhat.com, ezannoni@redhat.com References: <200209190804.BAA27599@otisco.McKusick.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209190804.BAA27599@otisco.McKusick.COM> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00476.txt.bz2 On Thu, Sep 19, 2002 at 01:04:10AM -0700, Paul N. Hilfinger wrote: > > > I think the changes are pretty straightforward, though I'd appreciate > > it if somebody more conversant with ada-lang.c than I am could make > > sure I'm not missing anything with my change there. > > David, > > OK; let me explain what Ada is up to in the various places it does > symbol lookup, and you can decide if we (ahem) need a conversation on > this (vis-a-vis this thread or the other "dictionary" threads), or if > our needs introduce no new requirements. > > The problem is that some of our symbol lookups essentially require searches for > regular expressions of the form > > (.*__)?(___.*)? > > or for > > (___.*)? > > Not much you can do about the former, of course, with the current > setup, except scan all symbols, and that's what we do. The second > pattern, however, can benefit for sorted blocks in an obvious way--- > hence the ada-lang.c code you mentioned in an earlier message---but > doesn't need them. That is, we take advantage of BLOCK_SHOULD_SORT > when possible. I don't have measurements of the impact of not having > it. There are obvious ways to use caching when performance becomes a > problem (and we currently use them). > > The other property of Ada is that when we have to search global or > all file-scope symbols, we generally want ALL matches to these patterns, or > ALL matches from a given block. Paul, David, I believe that the right thing to do with this code is actually to tranform it into calls to search_symbols and let that handle the details. We have a regexp symbol matching interface... and it's not significantly slower, given that almost no symbol tables are sorted now anyway. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer