From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14399 invoked by alias); 9 Apr 2002 01:59:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14380 invoked from network); 9 Apr 2002 01:59:18 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 9 Apr 2002 01:59:18 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16ukun-0003nn-00; Mon, 08 Apr 2002 21:59:21 -0400 Date: Mon, 08 Apr 2002 18:59:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com, Benjamin Kosnik , Daniel Berlin Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020408215921.B14098@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com, Benjamin Kosnik , Daniel Berlin References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00109.txt.bz2 On Mon, Apr 08, 2002 at 07:02:58PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > GDB already does a great deal of this by the very simple method of > > using fully qualified names. It's served us remarkably well, although > > of course we're hitting its limits now. But let's not be too quick to > > discard that approach, for the present at least. > > Oh dear. I think that's exactly what I'm proposing we replace. As > Per said: > In that situation, we can look up things like `B2::A2::x' in a > straightforward way: look up B2, look up A2 there, and look up x > there. With a symbol table full of fully qualified names, how do we > do this? > > Can you talk more about why we shouldn't evolve away from placing > fully qualified names in the symbol table directly, and towards > representing them more explicitly? Let me be a little clearer on what I wanted to say there: I agree completely that your approach is cleaner, more efficient, more adaptable, more useful, and generally better than what we have now. But let me put my cynic's cap on for a moment and point out some problems. I'd love to see us just decide to overcome them all, and I think it's viable, but we need to make sure we consider them first. The "incremental change" Problem Could we write the necessary wrapper functions to simulate lookup of a fully qualified name and use them everywhere we haven't changed yet? Probably a non-issue. How much will have to be changed at first to make this functional? For instance, all the debug readers would be substantially affected. The "big change" Problem There's plenty of places in GDB that assume the current name lookup behavior. We'd have to do a lot of digging to make sure we did scoped lookups everywhere that needed them. On the upside, we could use this as an excuse for some really rocking test coverage improvements. The "debug info" Problem DWARF-2 gives us enough information for this. Sun's stabs extensions (well, recent definitions; it being their format and all) also give us enough information. HP's stuff probably does, but I don't know if we've got anyone that knows it well enough to update. For most other formats, we'd just have to fake it as well as we could and hope for the best. Look at the debugging output GCC 3.0 / -gstabs+ puts out for namespaces or even nested classes sometime. I'm sure I had another in mind, but it slips my mind at the moment. For debug info, we could probably add a 'unknown_scope_kind' to the enum name_kind I described in my other message, and change all periods/colons etc. into those. For free, this hierarchy would let us associate out-of-line member function definitions directly with the types, which would make my life in C++-land much nicer! -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer