From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21443 invoked by alias); 27 Jun 2003 16:04:14 -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 21384 invoked from network); 27 Jun 2003 16:04:13 -0000 Received: from unknown (HELO hawaii.kealia.com) (216.101.126.244) by sources.redhat.com with SMTP; 27 Jun 2003 16:04:13 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id 762FBBED2; Fri, 27 Jun 2003 09:04:13 -0700 (PDT) To: gdb-patches@sources.redhat.com Cc: Elena Zannoni , Jim Blandy Subject: Re: [rfa] generate symbols associated to namespaces References: <20030622173547.GA22603@nevyn.them.org> <20030624185019.GA24662@nevyn.them.org> From: David Carlton Date: Fri, 27 Jun 2003 16:04:00 -0000 In-Reply-To: <20030624185019.GA24662@nevyn.them.org> (Daniel Jacobowitz's message of "Tue, 24 Jun 2003 14:50:19 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00816.txt.bz2 On Tue, 24 Jun 2003 14:50:19 -0400, Daniel Jacobowitz said: > On Tue, Jun 24, 2003 at 11:31:36AM -0700, David Carlton wrote: >> On Sun, 22 Jun 2003 13:35:47 -0400, Daniel Jacobowitz said: >>> 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. Yes. Unfortunately, if we do a hasty job at this, we'll have a new favorite bug in C++, namely people asking what all these "" messages are about, and why they can no longer print out members of classes that they used to be able to. :-( (Incidentally, in regards to constructor breakpoints, it looks less likely than it did a couple of months ago that I'll have time to work on that. So if you need an outlet for your considerable energies, feel free to work on that one. :-) ) > 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... You'd be surprised. (Or at least I was.) It turns out that it's not all that uncommon for type deduction to fail in ways that confuse lookup_transparent_type no end. Sigh. Anyways, don't worry: we really are making progress on this, and it really will be there for 6.1. >>> 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. You're probably right; I'll treat them like normal symbols, then. I've looked at your code comments, and they all seem reasonable. I hope I'll have a revised version of the patch today; job transition issues will take up some of my time (I start full-time work at Kealia today, so I have to figure out what they want me to do other than hack GDB), but it's near the top of my priority list. David Carlton carlton@kealia.com