This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: current namespace game plan
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