This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: struct environment
- From: Andrew Cagney <ac131313 at ges dot redhat dot com>
- To: David Carlton <carlton at math dot stanford dot edu>
- Cc: gdb <gdb at sources dot redhat dot com>
- Date: Tue, 17 Sep 2002 03:47:36 -0400
- Subject: Re: struct environment
- References: <ro1lm6gcg9r.fsf@jackfruit.Stanford.EDU>
David,
Per the original thread, this should be prototyped on a branch (you can
then cut your self loose for a bit :-).
Having done this for regcache and reggroup it is worth it -> you get to
see what actually works rather than what everyone else thinks should
work. You can also pick out the cleanups that will make the final
change easier. For instance - tightening up the way GDB creates symbol
tables (DanielB suggested moving psymtab into stabs) an performs lookups
on them.
--
Btw, try ``struct nametab''? These are just tables for mapping a name
onto a symbol?
--
Have a look at how I've been evolving ``struct frame_info'' and ``struct
cmd_list_element[?]'':
- tighten up the existing interface so that you know how things are
really used (rather than how you think things are used). My trick was
to do a temp rename of a field and then convert to accessor methods
anything that didn't compile.
- with a tight interface, re-implement the internals.
--
Having also gone over the original thread, two things come to mind:
- what effect will this have on GDB's foot print? The original proposal
was to put these things everwhere (structs, unions, ...). I don't think
that is necessary and would cause serious bloat. Instead, initially, I
think these tables could be simple linear lists (that is what ``struct
block'' currently implements so it can't be any worse :-) (just the
global / final table is special :-).
- Am I correct to think that the objective is to create a directed
acyclic graph of nametabs and have lookups search through each in turn.
--
In terms of operations, I would concentrate on determing exactly GDB
needs (rather than you think it needs) GDB is 15 years old so chance
has it the operations have been identified already. I know of two
operations off hand:
print foo
which gets turned into struct symbol *lookup("foo",``block'') and,
print foo<tab>
which turns into ``const char **tabexpand("foo", ``block'')''. Any others?
Andrew