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


On Tue, Sep 17, 2002 at 11:59:05AM -0400, Andrew Cagney wrote:
> >On Tue, Sep 17, 2002 at 03:47:36AM -0400, Andrew Cagney wrote:
> >
> >>Btw, try ``struct nametab''?  These are just tables for mapping a name 
> >>onto a symbol?
> >
> >
> >Hmm..
> >
> >
> >>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 :-).
> >
> >
> >Why do you think this will cause any bloat?  This is why David
> >suggested a model of block with a linear list implementation.
> 
> That is good news, the early discussion was describing a totally generic 
> implementation being applied to everything.  Can I assume that no one 
> has immediate plans for adding this to the type system?

Not sure what you mean.  I don't see any problem with the way David
described it - a dictionary which could be ordered (list) or unordered
(hash) depending on the context.  I wouldn't call that overengineered.

> >>- 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.
> >
> >
> >Well, sort of.  It won't be a DAG necessarily (I think that mutual
> >"using" statements are legal in C++; I remember a GCC bug involving
> >them was fixed not long ago), and it will be somewhat complicated
> >figuring out which ones to look up (namespace links are different than
> >block scope links).
> 
> Don't forget that GDB doesn't need to model the language.  Just the 
> namespace behavior at a given PC.  The effect of "using" would be to 
> just grow a nametab in someway.

This is legal C++:

namespace D {}

namespace C { 
  using namespace D;
  int x, y;
}

namespace D {
  using namespace C;
  int x, z;
}

If using just grew a nametab we'd get into a great deal of trouble.

> >>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?
> >
> >
> >At least iterate over all, search regexp.
> 
> Yes (iterate over would come from things like ``info locals'').  Regex 
> (I know it's used somewhere)?

search_symbols?  The plan is not to stop with blocks; the point is to
use the same interface for the global symbol tables also.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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