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: new demangler


On Wed, Dec 17, 2003 at 09:58:29PM -0500, Ian Lance Taylor wrote:
> Jim Blandy <jimb@redhat.com> writes:
> 
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > > When I can figure out a few more points of C++ grammar - it's taken me
> > > a *(!&#@ month so far and it's barely functional... - I'll have an
> > > efficient solution for breaking down names into the demangler's trees. 
> > > This will let us get the information we want much more reliably.
> > 
> > When working on big C++ programs, I think I remember seeing that the
> > mangled and demangled names take up a *lot* of memory.
> > 
> > If that recollection is correct, it might be cool to have GDB store
> > the trees instead of the names, and throw a bcache at the nodes in
> > these demangled name trees, working from the leaves upward, to get
> > maximum sharing.  I bet that would bring the memory requirements down
> > to something more closely resembling the actual number of classes,
> > methods, etc. in the program.

I don't know how well it would work compared to simply cutting down on
the number of demangled names we need in memory.  Specifically, instead
of one symbol table with fully qualified names, lots of little
dictionaries with the names of members.

> > I think the trees would be a lot easier to do certain kinds of
> > matching on, too.  "Is this a user-defined cast operator?"
> 
> Tangentially, note that the trees that I wrote for the demangler are
> based pretty directly on the mangling ABI.  They just follow the
> grammar productions used there.
> 
> To use them for anything other than demangling, it might be useful to
> try to work out a good tree representation for C++ names.  Then I or
> somebody can modify the demangler to use that tree representation
> instead.  It would probably be pretty close to the trees I use, but I
> doubt it would be identical.

So far, simply using yours hasn't been a problem.  A few of my rules
are a little awkward, but compared to the hacks normally found in yacc
grammars it's a downright beauty.

Was anything ever decided about conversion operators and typeof()?

-- 
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]