Re: [rfa] generate symbols associated to namespaces

[David Carlton <carlton at math dot stanford dot edu>]

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,
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
number of bug reports that I'm getting is definitely dwindling; on the
other hand, I know some areas that the branch probably gets wrong
currently that Kealia doesn't happen to use in its code.  So I really
want this stuff to go in earlier in a release cycle, so we can test it
in more real-world environments before releasing it at large.

It also doesn't help that the bugs that I've been seeing are really,
really hard to reduce to a small test case: they frequently involve
psymtab/symtab interactions, and they also frequently involve large
files that happen to cause certain versions of GCC to generate the
DIEs in some particular, unfortunate order.  If we release a version
without a lot of testing, we'll get a lot of bug reports from people
who say "GDB fails in this situation, but I have no idea how to reduce
the bug report in order to make it possible for you to fix it."

> 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'd really appreciate it if you did this differently in the future. 
> Believe it or not, I had C++ debugging working very nicely with stabs;
> you don't need to make new tests pass with stabs, but please check that
> you do not cause existing tests to regress.

> The runtest invocation you'd need for this is "runtest --target_board
> unix/gdb:debug_flags=-gstabs+".

Thanks, will do.

> It appears that your new code does not work with stabs debugging.  When
> dwarf2-frame.c reaches the fake objfile, it gets an internal error
> because SECT_OFF_TEXT is not initialized.

Whoops, sorry about that.  For what it's worth, any problems that
occur here would probably also occur with Java debugging, because they
also use a fake objfile, so it's just as well that you're fixing that,
even though I'll get rid of the objfile.

> This appears to be a problem
> in the dwarf2-frame code and I just sent a separate message about it.
> With a workaround for that in place, the results for stabs look OK.

Great.

> The three new tests fail:
> +FAIL: gdb.c++/namespace.exp: ptype C
> +FAIL: gdb.c++/namespace.exp: ptype E
> +FAIL: gdb.c++/namespace.exp: maint cplus namespace

> (Most of the other tests in namespace.exp fail too.)

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.

3) In GCC 2.95.3 (with stabs, probably also with DWARF 2), anonymous
   namespaces get demangled to "{anonymous}" instead of "(anonymous
   namespace)", so I'm looking for the wrong string.  (This isn't a
   big deal, since GCC 2.95.3's namespace support is bad enough that
   any serious namespace users will be using 3.x.)

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.)

Thanks for the comments on the code; I'll look at them in more detail
tomorrow.

David Carlton
carlton@math.stanford.edu