This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: current namespace game plan


On Wed, 23 Oct 2002 19:36:22 -0400, Andrew Cagney <ac131313@redhat.com> said:

> Anyway, to this end I've several idea's:

> - Tighten the symtab - core-gdb interface
> Here, the objective is to confine the symbol table readers to a very
> small arena so that you know exactly how GDB uses them.  Since GDB
> accesses things though a very tight interface, the symtab code gets
> closer to plug-and-play - drop in a new reader and test it.

I'm working on doing this in ways that are useful to me.  (Well, not
quite: I'm interested in the specific task of associating names and
symbols, which is less general than "the symbol table readers".)  The
current situation isn't that bad: what's important to me is that I
know how to store data relevant to symbols (actual symbols, as opposed
to minimal symbols), how to look up names in various environments (in
a particular block, in the global environment, etc.), and how the
presence of minimal symbols and partial symbols affects this.

The building stuff that's relevant to me is already centralized in
buildsym.c.  Looking up symbols is in lookup_symbol (well,
lookup_symbol_aux) and search_symbol; I've tamed the former enough to
make me happy for now (i.e. I can now look up stuff in the global
environment by calling lookup_symbol_aux_nonlocal: the innards of that
function might be messy, but that's a separate issue), and I'll move
on to the latter soon.  The presence of partial and minimal symbols
certainly affects searches in the global environment; I've been
pleased at how effective it's been to encapsulate that all in
lookup_symbol_aux_nonlocal, however.

> - Push the partial symtab code into the stabs reader.
> That way, all the partial symtab bufuddlement isn't in core GDB and
> you, and no one else, has to content with it.

Gee, thanks, being a stabs expert is really what I have my heart set
on right now. :-)

Honestly, one of the things on my to do list is to rework how global
symbol lookup is handled, which might involve the sort of things
you're talking about.  Having said that, it keeps on going further and
further down my to do list, because I keep on getting surprised at how
little the current state of affairs gets in the way of adding
namespace support.  First, I thought I needed it to do any namespace
work; then I thought I needed it to do namespaces properly (as
first-class objects); now I'm pretty sure that I'll be able to do
namespaces as first class objects without that.  I still suspect that
I'll want to add iterators to namespace lookups (or to any symbol
lookups, really), and it's not at all clear to me that that will work
well with the current framework, but it's also not at all clear that
it won't.

> - eliminate all that symbol table memory mapping stuff

Is this xmmalloc and friends?  I just noticed that maybe three weeks
ago.  I was all ready to cut it all out until somebody claimed that
Apple uses it.  If it's true that it's useful to Apple, then it's not
clear to me that it's urgent to cut it out, since I don't think it's
particularly causing problems right now.  But I like deleting code, so
if you can build a consensus that this should go, let me know and I'll
be happy to handle it.  At the very least, we might as well check with
the relevant Apple people: if they don't think its presence in
mainline GDB is helpful to them (either because they don't use it
after all or because they've made so many changes to GDB to support it
that it won't make a difference if we axe it) then we should get rid
of it.

David Carlton
carlton@math.stanford.edu


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]