From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17026 invoked by alias); 16 Apr 2003 20:05:39 -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 17017 invoked from network); 16 Apr 2003 20:05:38 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 16 Apr 2003 20:05:38 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h3GK5bs27437; Wed, 16 Apr 2003 13:05:37 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb Cc: Elena Zannoni , Jim Blandy Subject: [rfc] struct dictionary From: David Carlton Date: Wed, 16 Apr 2003 20:05:00 -0000 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/msg00177.txt.bz2 I'd like to propose abstracting the symbol-storage parts of struct block into a new struct dictionary. Some background: Blocks currently store symbols in one of three different ways: using a hash table, using an unsorted list, or using a sorted list. Most blocks are built by buildsym.c, which use only the former two mechanisms. Sorted list blocks are only being produced by mdebugread.c. And, to make matters worse, jv-lang.c produces one unsorted list block for which the predicate BLOCK_SHOULD_SORT matches; the chain of events by which GDB actually treats that block correctly is very tenuous. This sucks. We have this code to handle sorted linear blocks, but we almost never use them. We have this one block that's a complete special case, and it's remarkable that that block still works. And there are some other drawbacks. For example, the only iterator that we provide is ALL_BLOCK_SYMBOLS; it would be nice if we could provide an iterator over all symbols with a given demangled name (e.g. for use by make_symbol_overload_list), which would be implemented efficiently in the hash table case and less efficiently in the linear case, but we have no way of doing that currently. The block code currently isn't quite legal C; it's illegal in a way that wouldn't normally bother me, but these days I don't trust the GCC people to not break anything that's the slightest bit illegal. The Java code needs blocks that expand: this is very hard to do with the current structure, and I could imagine other places in GDB where this might be useful. And probably at some point in the future, somebody will find a good reason to add a new data structure for storing symbols (e.g. to optimize completion or regexp searces or something); doing so with the current architecture would be very difficult. So I'd like to fix all of that. I want to do this by moving that part of struct block into a new struct called 'struct dictionary'. This would be an opaque data type; it has accessor functions to do everything that you need to do to access symbols. I've been using this on my branch for months; it works great. The only thing that I'm not sure about is if I got mdebugread.c right, since I have no way to test that; I'm confident that I can fix any problems that might arise there with a little help from testers. So: should I go ahead with this, and prepare a formal RFA? (I'm a little busy right now; it won't happen this week, but maybe next week or the following week.) I'm including a copy of my branch's dictionary.h after my signature so you can see the current interface that I'm using. It's a little out of date - e.g. it refers to SYMBOL_BEST_NAME which was my old name for SYMBOL_NATURAL_NAME - but hopefully it's understandable enough to be useful. David Carlton carlton@math.stanford.edu /* Routines for name->symbol lookups in GDB. Copyright 2002 Free Software Foundation, Inc. Contributed by David Carlton . This file is part of GDB. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ /* An opaque type for dictionaries; only dictionary.c should know about its innards. */ struct dictionary; /* Other types needed for declarations. */ struct symbol; struct obstack; struct pending; /* The creation functions for various implementations of dictionaries. */ /* Create a dictionary implemented via a fixed-size hashtable. All memory it uses is allocated on OBSTACK; the environment is initialized from SYMBOL_LIST. */ extern struct dictionary *dict_create_hashed (struct obstack *obstack, const struct pending *symbol_list); /* Create a dictionary implemented via a hashtable that grows as necessary. The dictionary is initially empty; to add symbols to it, call dict_add_symbol(). Call dict_free() when you're done with it. */ extern struct dictionary *dict_create_hashed_expandable (void); /* Create a dictionary implemented via a fixed-size array. All memory it uses is allocated on OBSTACK; the environment is initialized from the SYMBOL_LIST. The symbols are ordered in the same order that they're found in SYMBOL_LIST. */ extern struct dictionary *dict_create_linear (struct obstack *obstack, const struct pending *symbol_list); /* Create a dictionary implemented via an array that grows as necessary. The dictionary is initially empty; to add symbols to it, call dict_add_symbol(). Call dict_free() when you're done with it. */ extern struct dictionary *dict_create_linear_expandable (void); /* The functions providing the interface to dictionaries. */ /* Search DICT for a symbol whose SYMBOL_BEST_NAME is NAME, as tested using strcmp_iw. Returns NULL if there is no such symbol. If there might be multiple such symbols, use dict_iter_name_first and dict_iter_name_next. */ /* FIXME: carlton/2002-09-26: Given the presence of dict_iter_name_first and dict_iter_name_next, should this function go away? Currently, it's never called, because all uses need the additional flexibility provided by dict_iter_name_first and dict_iter_name_next. */ extern struct symbol *dict_lookup (const struct dictionary *dict, const char *name); /* Free the memory used by a dictionary that's not on an obstack. (If any.) */ extern void dict_free (struct dictionary *dict); /* Add a symbol to an expandable dictionary. */ extern void dict_add_symbol (struct dictionary *dict, struct symbol *sym); /* Is the dictionary empty? */ extern int dict_empty (struct dictionary *dict); /* A type containing data that is used when iterating over all symbols in a dictionary. */ /* NOTE: carlton/2002-09-11: I originally wanted to make this opaque, but that led to complications. Fortunately, it turned out that all implementations of dictionaries currently need to keep track of the same types of data (though how they interpret that data varies depending on the implementation), so it's really not so bad after all. But code outside of dictionary.c should never examine the innards of a dict_iterator. */ struct dict_iterator { /* The dictionary that this iterator is associated to. */ const struct dictionary *dict; /* The next two members are data that is used in a way that depends on DICT's implementation type. */ int index; struct symbol *current; }; /* Initialize ITERATOR to point at the first symbol in DICT, and return that first symbol, or NULL if DICT is empty. */ extern struct symbol *dict_iterator_first (const struct dictionary *dict, struct dict_iterator *iterator); /* Advance ITERATOR, and return the next symbol, or NULL if there are no more symbols. Don't call this if you've previously received NULL from dict_iterator_first or dict_iterator_next on this iteration. */ extern struct symbol *dict_iterator_next (struct dict_iterator *iterator); /* Initialize ITERATOR to point at the first symbol in DICT whose SYMBOL_BEST_NAME is NAME (as tested using strcmp_iw), and return that first symbol, or NULL if there are no such symbols. */ extern struct symbol *dict_iter_name_first (const struct dictionary *dict, const char *name, struct dict_iterator *iterator); /* Advance ITERATOR to point at the next symbol in DICT whose SYMBOL_BEST_NAME is NAME (as tested using strcmp_iw), or NULL if there are no more such symbols. Don't call this if you've previously received NULL from dict_iterator_first or dict_iterator_next on this iteration. And don't call it unless ITERATOR was created by a previous call to dict_iter_name_first with the same NAME. */ extern struct symbol *dict_iter_name_next (const char *name, struct dict_iterator *iterator); /* Macro to loop through all symbols in a dictionary DICT, in no particular order. ITER is a struct dict_iterator (NOTE: __not__ a struct dict_iterator *), and SYM points to the current symbol. It's implemented as a single loop, so you can terminate the loop early by a break if you desire. */ #define ALL_DICT_SYMBOLS(dict, iter, sym) \ for ((sym) = dict_iterator_first ((dict), &(iter)); \ (sym); \ (sym) = dict_iterator_next (&(iter))) /* For backwards compatibility, I suppose. */ #define ALL_BLOCK_SYMBOLS(block, iter, sym) \ ALL_DICT_SYMBOLS (BLOCK_DICT (block), iter, sym)