From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17870 invoked by alias); 24 Jun 2003 19:00:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15077 invoked from network); 24 Jun 2003 18:31:41 -0000 Received: from unknown (HELO smtp8.Stanford.EDU) (171.67.16.35) by sources.redhat.com with SMTP; 24 Jun 2003 18:31:41 -0000 Received: (from root@localhost) by smtp8.Stanford.EDU (8.12.9/8.12.9) id h5OIVeMg019201 for gdb-patches@sources.redhat.com; Tue, 24 Jun 2003 11:31:40 -0700 (PDT) Received: from jackfruit.Stanford.EDU (jackfruit.Stanford.EDU [171.64.38.136]) by smtp8.Stanford.EDU (8.12.9/8.12.9) with ESMTP id h5OIVacT019181; Tue, 24 Jun 2003 11:31:37 -0700 (PDT) Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h5OIVas13233; Tue, 24 Jun 2003 11:31:36 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Elena Zannoni , Jim Blandy Subject: Re: [rfa] generate symbols associated to namespaces References: <20030622173547.GA22603@nevyn.them.org> From: David Carlton Date: Tue, 24 Jun 2003 19:00:00 -0000 In-Reply-To: <20030622173547.GA22603@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00753.txt.bz2 On Sun, 22 Jun 2003 13:35:47 -0400, Daniel Jacobowitz 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