This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
[rfc] struct dictionary
- From: David Carlton <carlton at math dot stanford dot edu>
- To: gdb <gdb at sources dot redhat dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, Jim Blandy <jimb at redhat dot com>
- Date: 16 Apr 2003 13:05:37 -0700
- Subject: [rfc] struct dictionary
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 at math dot stanford dot edu
/* Routines for name->symbol lookups in GDB.
Copyright 2002 Free Software Foundation, Inc.
Contributed by David Carlton <carlton at bactrian dot org>.
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)