From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23173 invoked by alias); 22 Oct 2002 02:45:20 -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 23166 invoked from network); 22 Oct 2002 02:45:18 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 22 Oct 2002 02:45:18 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 183py8-0003if-00; Mon, 21 Oct 2002 22:44:37 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 183p2j-0006L3-00; Mon, 21 Oct 2002 22:45:17 -0400 Date: Mon, 21 Oct 2002 19:45: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: <20021022024516.GA24007@nevyn.them.org> Mail-Followup-To: David Carlton , gdb-patches@sources.redhat.com References: 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/msg00384.txt.bz2 On Mon, Oct 21, 2002 at 05:10:08PM -0700, David Carlton wrote: > Here's some code to add support in GDB for using directives; it uses > this to look up names from within functions defined in namespaces and > for anonymous namespaces. In the latter case, it uses DWARF 2 (DWARF > 3, actually) debugging info if its there; if not, it tries to deduce > it on its own. > > It contains the code in > ; I'm > including that because some of the relevant bits have changed (a few > bugs in the lookup_symbol stuff that I didn't find until multiple > using directives were in affect, and because struct using_direct has > changed a bit. Unfortunately, it's not done changing yet - the more I > understand the name lookup rules from the C++ Standard, the more of > the mess it looks like. So there are some bugs that I know about > involving in the way namespaces are handled in this code (basically, I > try to fake "namespace scope" by adding a bunch of using directives), > but it's a reasonable first start. Not ready for mainline, though. > > The modifications to the dwarf2read.c might be useful for you when > you're trying to get classes located in the correct namespace. > Tell me what you think. I realize that this is pretty large; I > promise that I won't submit another patch for approval to the branch > until this one (or a variant of it) has been approved, to cut down on > the sizes of future patches... It's approved, with some comments for you to think about. You're doing a truly heroic amount of work here... > +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... > + - And operator names can contain parentheses or angle brackets. > + Fortunately, I _think_ that operator names can only occur in a > + fairly restrictive set of locations (in particular, they have be > + at depth 0, don't they?). */ No :( This is one of the more hideous pieces of C++ I've ever written and it took a little time to come up with: class B { public: }; int operator+ (B const &, B const &) { return 1; } template class C { public: static void * const cmem = T; int member(void); }; int theInt; template int C::member(void) { return 0; } C<(void *) &theInt> theC; C<(void *) &operator+> theOtherC; int func() { return theOtherC.member(); } Gives us this gem: 00000000 W C<&operator+(B const &, B const &)>::member(void) 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? Oh. operator>>. Um.... this grosser revision of the above code: class B { public: }; int operator+ (B const &, B const &) { return 1; } int operator<< (B const &, B const &) { return 1; } int operator>> (B const &, B const &) { return 1; } template class C { public: static void * const cmem = T; int member(void); }; int theInt; template int C::member(void) { return 0; } C<(void *) &theInt> theC; C<(void *) &operator+> theOtherC; C<(void *) &operator<<> theThirdC; C<(void *) &operator>>> theFourthC; int func() { return theC.member() + theOtherC.member() + theThirdC.member() + theFourthC.member(); } Produces this terrifying output: 00000000 W C<&operator<<(B const &, B const &)>::member(void) 00000000 W C<&operator>>(B const &, B const &)>::member(void) So I guess we need to look for those specifically. That's awful. > + > +/* 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. > +/* 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. > +/* 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... > + /* 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? > + /* Contains information about what using directives or other > + similar features are added by this block. This should always > + be NULL for global blocks: if there are using directives that > + affect an entire file, put it in the static block. */ I really hate what tabs do after patch markers and quoting markers... :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer