Re: Export bits of the demangler's internal interface

[Daniel Jacobowitz <drow at mvista dot com>]

On Sun, Jan 04, 2004 at 11:58:11PM -0500, Daniel Jacobowitz wrote:
> On Sun, Jan 04, 2004 at 11:40:57PM -0500, Ian Lance Taylor wrote:
> > Daniel Jacobowitz <drow@mvista.com> writes:
> > 
> > > Yes, but it turns out that it was an almost perfect interface for what
> > > I needed - witness the total size of the changes I had to make, which
> > > is actually quite small.  If I had to design an interface for this
> > > (something which I was never especially good at), it would look pretty
> > > much the same.  If there's something you'd prefer, you'll have to
> > > suggest it yourself :)
> > 
> > What do you (and DJ, and anybody else) think about this sort of
> > interface?
> > 
> > I would envision putting this in demangle.h, rather than creating a
> > new header file.
> > 
> > This pushes the issue of memory allocation onto the caller, rather
> > than exporting the d_info structure which is used internally but has
> > little relevance for your purposes.
> > 
> > I considered hiding struct demangle_component and providing accessor
> > functions, but I decided that that wasn't worth it.  I don't think we
> > need to worry about binary compatibility among different releases.  I
> > hid the other structures because there was no present need to expose
> > them.  Your code only uses them to check for a void parameter to a
> > function, and you can solve that in other ways.
> 
> Yes, I can avoid needing D_PRINT_VOID - I just haven't gotten around to
> working out how yet.
> 
> I have one large problem with this interface, based on the design (only
> in my head so far, sorry) of how I want GDB to take advantage of this
> information. I was eventually going to send along a request to expose
> d_demangle too; I don't just build arbitrary trees and convert them to
> strings, I also convert both mangled and demangled names to trees, and
> analyze them.
> 
> For instance: to determine enclosing class or namespace scope; to
> determine a function's basename (there are better ways to do this for
> mangled names as discussed earlier); to determine a function's
> arguments when we lack debug info for it (this is often necessary for
> stabs); someday, to save a signficant amount of space in GDB's symbol
> tables for describing a function's name (by using a binary object cache
> to allocate objects - which is not really compatible with the opaque
> model).

For that last, the tree structure may not be appropriate at all anyway
- overhead worse than the cure.  I'm going to think about what I
actually need for a little while longer this time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer