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: struct environment


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


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