Re: current namespace game plan

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Oct 04, 2002 at 03:58:50PM -0700, David Carlton wrote:
> On Fri, 4 Oct 2002 18:11:17 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> 
> > You're skipping what I'd consider the most important step.
> 
> > We can't even get namespaces right when the user gives us a fully
> > qualified name.  We do it for variables and functions by resorting to
> > the minsym and physname.  But types?  No way.  They all get entered in
> > the top level.
> 
> Whoops; good thing I asked.
> 
> Types are a little tricky without proper debugging information.  But
> now I'm starting to remember some e-mails we had a month or so ago
> where we said that, for a class, you could figure out the type by
> looking at the physname of one of its members (possibly an implictly
> defined function, but there should always be something).  Which
> probably explains this:
> 
> >   - Inference support in both DWARF-2 and Stabs readers; I have the
> > prototypes of this all done.  We can correctly infer a type's full
> > name for everything but enums, I believe.
> 
> Because with enums, there's simply no way to get that information
> without improved debugging information.

Exactly.

> Fortunately, that sounds like it should complement the other stuff
> that I was proposing as the first step, and indeed should be
> orthogonal to that.  Do your changes create a symbol whose name is
> fully qualified and whose demangled_name is null?  That seems to me
> like it should work.

Not sure what to do for the symbols that go with types (which I'm not
sure should exist, anyway; they're (you guessed it) because that's how
stabs works).  That's probably what I'll settle on.  The type name is
fully qualified.

Things yet to be determined:
  - interaction with TYPE_TAG_NAME
  - interaction with Java
etc.  Type printing and type name handling are messed up all over GDB,
which is why this will take some doing.

> > And:
> >   - Code to not print excessive qualification on names, for
> > instance printing the fully qualified type in constructors; it's ugly
> > and causes needless testsuite churn.
> 
> Hmm.  I'll keep that in the back of my mind, but you'll probably have
> to remind me periodically that this is important.

Without it, for a type std::string (even assuming that were a type and
not the template gop it really is!), the argument lists get way out of
hand.

> > What I really should do is bundle up what I have onto a branch.  If
> > I feel inspired enough I'll try to do it tomorrow.  The last point
> > caused me to stop and focus on type printing and type correctness
> > for a bit, and I got completely sidetracked; a branch would help a
> > lot.
> 
> That would be great; and then one or the other of us could try to grab
> out chunks of that.  E.g. it seems to me that the type inference stuff
> that you mentioned would be an improvement to GDB right now, aside
> from any other further namespace improvements.

Except that it isn't without all the printing tweaks to keep output
succinct.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer