From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11530 invoked by alias); 22 Oct 2002 20:32:09 -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 11445 invoked from network); 22 Oct 2002 20:32:08 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Oct 2002 20:32: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 1846ck-0005HZ-00; Tue, 22 Oct 2002 16:31:38 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 1845hO-0001r2-00; Tue, 22 Oct 2002 16:32:22 -0400 Date: Tue, 22 Oct 2002 13:32:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: gdb-patches@sources.redhat.com Subject: Re: [drow-cplus-branch rfa] using directives support Message-ID: <20021022203222.GA6572@nevyn.them.org> Mail-Followup-To: David Carlton , gdb-patches@sources.redhat.com References: <20021022024516.GA24007@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/msg00417.txt.bz2 On Tue, Oct 22, 2002 at 01:18:34PM -0700, David Carlton wrote: > and where we're at a breakpoint inside of B::foo(), if we can get a > lookup of A::x to fail (and one of ::A::x to succeed), then that will > be pretty impressive. I'm not exactly looking forward to reworking > symbol lookup stuff to use iterators, either, or to getting Koenig > lookup to work. I think we can get it to happen. Eventually, at least. We're not quite close enough yet... > >> +static void > >> +scan_for_anonymous_namespaces (struct symbol *symbol) > >> +{ > >> + const char *name = SYMBOL_CPLUS_DEMANGLED_NAME (symbol); > >> + const char *beginning, *end; > >> + > >> + /* FIXME: carlton/2002-10-14: Should we do some sort of fast search > >> + first to see if the substring "(anonymous namespace)" occurs in > >> + name at all? */ > > > Definitely! This is a hideously expensive search here... > > Yah. What's the right way to do this? regex? There doesn't seem to > be anything appropriate in the C standard library. Well, there's strstr(). I don't know if it's portable, offhand, though. Better than regex would be a loop of strchr searches for '(' and strcmps, though, I think. > > Gives us this gem: > > 00000000 W C<&operator+(B const &, B const &)>::member(void) > > Gosh. Charming. Or something. I think I'll wait until somebody > submits a bug report complaining about that one. Isn't that gross? I'm going to save this message and someday I'll put it in the testsuite... > > Not sure if this presents a problem; the parentheses in an operator > > name will be matched, and you can't define an operator->, can you? > > Of course you can: this is C++, a language that allows you to redefine > &&, ||, and the comma operator. In fact, you define it all the time > when doing smart pointers. (And I just learned yesterday that > operator-> has its own peculiar semantics; see chapter 7 of > Alexandrescu's _Modern C++ Design_. But that's really not something > I'm worried about at all right now.) Excuse me; I was thinking of '.*'. Which of course can not be overridden. > >> +/* FIXME: carlton/2002-10-09: Do all the functions here handle all the > >> + above considerations correctly? */ > > > Almost certainly not; I hadn't thought about the (anonymous namespace) > > thing. It may be misdetected as the arg list; if it isn't, it's blind > > luck. > > I skimmed it, and actually I think you were lucky: basically, you're > okay since (anonymous namespace) can never occur after the arg list, > just before it (or in the middle of it), and you search from the back > instead of the front. Whew! > >> +/* Let's optimize away calls to strlen("operator"). */ > >> + > >> +#define LENGTH_OF_OPERATOR 8 > > > A recent GCC will do this for you, actually. If glibc doesn't get in > > its way, at least. > > Hmm. I don't think I want to put those strlen()s any place where they > could be called more than once, but I could consider doing > > static const int length_of_operator = strlen("operator"); > > instead. That wouldn't have much of a performance penalty on other > compilers. It's fine the way it is, I think. > >> +/* FIXME: carlton/2002-10-07: That anonymous namespace example isn't > >> + that great, since it really depends not only on what the > >> + demangler's output is but also on the fact that the demangler's > >> + output doesn't depend on the name of the file in question. Which, > >> + alas, it doesn't, but should, leaving us with no way to distinguish > >> + between anonymous namespaces in different files. Sigh... */ > > > They may be responsive to fixing that... > > Yeah, I'll think about that. It's an easy enough hack to handle this > correctly within GDB, but it's still a hack. There is one benefit to > the current framework: if a user wants to explicitly refer to > anonymous namespaces, then it would be easier for the user to just > have to write '(anonymous namespace)::foo' instead of some more > complicated demangled thing. But I don't know how likely that is. But mightn't the user need to refer to more than one of the anonymous namespaces? > >> + /* FIXME: carlton/2002-10-10: is "is_a_field_of_this" always > >> + non-NULL if we're in the C++ case? Maybe we should always do > >> + this, and delete the two previous searches: this will always > >> + search the global namespace, after all. */ > > > I don't think it'll always be non-NULL - I think it's just set when the > > caller cares about the answer. And why are searches in using > > directives conditioned on this argument? > > Okay, then I'll change that accordingly; when we get around to merging > it into mainline, we can revisit the issue. Sure. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer