Re: [rfa] generate symbols associated to namespaces

Daniel Jacobowitz
2003-06-24T19:02:34Z

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