Re: [rfa] generate symbols associated to namespaces

[Daniel Jacobowitz <drow at mvista dot com>]

On Tue, Jun 24, 2003 at 11:31:36AM -0700, David Carlton wrote:
> On Sun, 22 Jun 2003 13:35:47 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> 
> > [First, a request: could your next namespace patch be the
> > fully-qualified name inference code for full symbols?
> 
> [ I'm only sort of back from vacation; I'll be really back tomorrow.
> Anyways... ]
> 
> My plan is for the next patch to be a smallish one which has the
> parser handle :: better.  But fully-qualified name inference, nested
> types, and all that fun stuff will come after that.  Having said that:
> 
> > I'd really, really like to see that in the next release of GDB; we'll
> > see...]
> 
> I don't think this is a good idea.  First, looking through my mailbox,

I'll bow to your judgement on this.  Right now it's our
second-most-often reported bug in C++, after the constructor
breakpoints thing.

However, if we do a limited form of inference - just
DW_AT_MIPS_linkage_name based - I think the risk is much smaller.  If
we have time to play with it...

> the branch is about to happen (or has just happened?), and we're not
> supposed to add new features.  More importantly, though, fully
> qualified types is a really large change.  It's much larger than I
> realized it was before I started working at Kealia: if we don't have
> DW_TAG_namespace, then there is a quite subtle balancing act going on
> between the demangler and the names that are in DW_AT_name, and
> between getting type names right whenever possible and resigning
> ourselves to some lookup_transparent_type failures.  If we do have
> DW_TAG_namespace, then I'm still not done tracing down situations
> where we run into problems because of DIE cross-references.  The

No, you definitely aren't.  I noticed another looking at your branch
the other day, I think.

> > While it is true that namespaces may be shared across objfiles, and
> > it is true that it's more elegant to hold them separately from any
> > objefile, you're creating an always-expanding list of namespaces.
> > They will never be freed.  Consider the problems this can cause:
> 
> > prog1.cc:
> > namespace A {
> >   namespace A { int oops; }
> >   int x;
> >   void foo() { /* A::x; error */ x; }
> > }
> 
> > prog2.cc:
> > namespace A {
> >   int x;
> >   void foo() { A::x; /* no error */ }
> > }
> 
> > ./gdb prog1
> > ...
> > (gdb) maint cplus namespace 
> > Definite namespaces:
> > Possible namespaces:
> > A::A
> > A
> > (gdb) file ./prog2
> > Load new symbol table from "./prog2"? (y or n) y
> > Reading symbols from ./prog2...done.
> > (gdb) maint cplus namespace 
> > Definite namespaces:
> > Possible namespaces:
> > A::A
> > A
> 
> > Oops!  You've still got A::A as a namespace.
> 
> > In addition there are memory concerns with this fake objfile.  All
> > in all, I don't think this use of fake objfiles is legitimate.  I
> > think you're going to have to tie a fake block to each objfile
> > instead, which should be an acceptable compromise.  Definite
> > namespaces would go in the global block of any objfile where they
> > are found, possible namespaces would go in a special block in any
> > objfile in which they are inferred.
> > lookup_possible_namespace_symbol will gain a loop over all objfiles.
> > A few functions will have to take an objfile parameter.
> 
> That sounds sensible: I guess I hadn't really realized how objfiles
> work.  I understand and agree with you about the possible namespace
> symbol stuff, but let me double-check on what you want with definite
> namespace symbols: should I stick those in each symtab where they're
> found, or should I put them in a special symtab (one per objfile, of
> course)?  Either way is fine with me.

I would prefer them in the normal global block, but if you've got a
reason to do it the other way that's good too.  I believe, with some
minor massaging, that this will be easier.  And it's fewer special
cases.

> 
> Yeah.  There are at least three problems with stabs namespace tests
> that I'm aware of:
> 
> 1) Some of what I'm doing (e.g. this patch) requires modifying the
>    actual reader to get the new functionality; I've only done that
>    with DWARF 2.  That's why the above new tests fail.
> 
> 2) Some of the generic buildsym code depends on having access to
>    mangled names; GCC 3.x doesn't give us those when doing stabs
>    debugging.

It always provides the mangled names for methods.  Not for functions, I
suppose.

> Parts 1 and 2 will wait until somebody with the appropriate motivation
> addresses them; we've talked about that before, of course.  I assume
> part 3 is trivial to fix, so I'll deal with that at some point when I
> have a free moment.  (I have, reluctantly, come to the conclusion that
> I'll have to start tweaking the various demanglers' outputs.  Sigh.)

I'd still rather not do this.  I have some ideas, but they're
definitely long-term.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer