This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] delete BLOCK_SHOULD_SORT
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Hilfinger at otisco dot mckusick dot com
- Cc: carlton at math dot stanford dot edu, gdb-patches at sources dot redhat dot com,aidan at velvet dot net, jimb at redhat dot com, ezannoni at redhat dot com
- Date: Thu, 19 Sep 2002 09:29:23 -0400
- Subject: Re: [RFA] delete BLOCK_SHOULD_SORT
- References: <ro1u1knrlkj.fsf@jackfruit.Stanford.EDU> <200209190804.BAA27599@otisco.McKusick.COM>
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
>
> (.*__)?<NAME>(___.*)?
>
> or for
>
> <NAME>(___.*)?
>
> 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