From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4968 invoked by alias); 5 Oct 2002 00:18:08 -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 4961 invoked from network); 5 Oct 2002 00:18:08 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 5 Oct 2002 00:18:08 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17xdZq-0000lV-00; Fri, 04 Oct 2002 20:17:54 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17xceU-0006ep-00; Fri, 04 Oct 2002 20:18:38 -0400 Date: Fri, 04 Oct 2002 17:18:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb Subject: Re: current namespace game plan Message-ID: <20021005001838.GA25353@nevyn.them.org> Mail-Followup-To: David Carlton , gdb References: <20021004221117.GA21018@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00052.txt.bz2 On Fri, Oct 04, 2002 at 03:58:50PM -0700, David Carlton wrote: > On Fri, 4 Oct 2002 18:11:17 -0400, Daniel Jacobowitz said: > > > You're skipping what I'd consider the most important step. > > > We can't even get namespaces right when the user gives us a fully > > qualified name. We do it for variables and functions by resorting to > > the minsym and physname. But types? No way. They all get entered in > > the top level. > > Whoops; good thing I asked. > > Types are a little tricky without proper debugging information. But > now I'm starting to remember some e-mails we had a month or so ago > where we said that, for a class, you could figure out the type by > looking at the physname of one of its members (possibly an implictly > defined function, but there should always be something). Which > probably explains this: > > > - Inference support in both DWARF-2 and Stabs readers; I have the > > prototypes of this all done. We can correctly infer a type's full > > name for everything but enums, I believe. > > Because with enums, there's simply no way to get that information > without improved debugging information. Exactly. > Fortunately, that sounds like it should complement the other stuff > that I was proposing as the first step, and indeed should be > orthogonal to that. Do your changes create a symbol whose name is > fully qualified and whose demangled_name is null? That seems to me > like it should work. Not sure what to do for the symbols that go with types (which I'm not sure should exist, anyway; they're (you guessed it) because that's how stabs works). That's probably what I'll settle on. The type name is fully qualified. Things yet to be determined: - interaction with TYPE_TAG_NAME - interaction with Java etc. Type printing and type name handling are messed up all over GDB, which is why this will take some doing. > > And: > > - Code to not print excessive qualification on names, for > > instance printing the fully qualified type in constructors; it's ugly > > and causes needless testsuite churn. > > Hmm. I'll keep that in the back of my mind, but you'll probably have > to remind me periodically that this is important. Without it, for a type std::string (even assuming that were a type and not the template gop it really is!), the argument lists get way out of hand. > > What I really should do is bundle up what I have onto a branch. If > > I feel inspired enough I'll try to do it tomorrow. The last point > > caused me to stop and focus on type printing and type correctness > > for a bit, and I got completely sidetracked; a branch would help a > > lot. > > That would be great; and then one or the other of us could try to grab > out chunks of that. E.g. it seems to me that the type inference stuff > that you mentioned would be an improvement to GDB right now, aside > from any other further namespace improvements. Except that it isn't without all the printing tweaks to keep output succinct. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer