From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11009 invoked by alias); 16 Jun 2010 21:30:23 -0000 Received: (qmail 10988 invoked by uid 22791); 16 Jun 2010 21:30:21 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jun 2010 21:30:11 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5GLU9Lp014459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 16 Jun 2010 17:30:10 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5GLU9fN023306; Wed, 16 Jun 2010 17:30:09 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o5GLU8Ej009999; Wed, 16 Jun 2010 17:30:08 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id AD45A3782E3; Wed, 16 Jun 2010 15:30:07 -0600 (MDT) From: Tom Tromey To: Jan Kratochvil Cc: gdb-patches@sourceware.org, Sami Wagiaalla Subject: Re: [patch 1/2] Search typedefs in namespaces also in other files References: <20100614155939.GA23639@host0.dyn.jankratochvil.net> Reply-To: tromey@redhat.com Date: Wed, 16 Jun 2010 21:30:00 -0000 In-Reply-To: <20100614155939.GA23639@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Mon, 14 Jun 2010 17:59:39 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00377.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Jan> currently you can access static symbols from not-current CUs Jan> (Compilation Units). In some cases you cannot if it is a name Jan> contained in namespace. Jan> It is questionable how it should behave. Such access is already Jan> not compliant with the C++ standard. The implementation tries only Jan> to search for the fully qualified names - without any attempts for Jan> imported namespaces. Well... AFAIK, types don't have linkage. And, in C++, due to the ODR, presumably anything like this must have a single meaning (though of course in reality we probably have fun cases with hidden symbols in .sos and whatnot). Finally, GCC may omit some debuginfo that it thinks is not useful in the current CU... so in some cases this patch may actually improve conformance; and anyway it is similar to what gdb already does, and also helpful. So I am inclined to think it is ok. It is true that it can yield confusing results, just as gdb already can in some cases. I think that must be reasonably rare, because I haven't seen any bug reports about it. In any case I think the way forward is to fix those cases somehow, not limit new ones. Jan> Already the C++ parser calls various functions in not so correct Jan> way IMHO I'm curious to know what. Jan> [Bug c++/11703] New: root namespace sometimes not working Jan> - Leading :: works only for types, not other objects. Jan> - IMHO a fix requires patching the C++ parser: -> archer-cpparser I think it could probably be solved, but that isn't too important. We'll fix it one way or another. Thanks for filing that. Jan> + /* Now search all static file-level symbols. Not strictly correct, Jan> + but more useful than an error. We do not try to guess any imported Jan> + namespace as even the fully specified namespace seach is is already not Jan> + C++ compliant and more assumptions could make it too magic. */ Jan> + Jan> + if (scope[0] == '\0') Jan> + { Jan> + sym = lookup_static_symbol_aux (name, domain); I'm having trouble following all the logic. I think lookup_symbol_aux calls la_lookup_symbol_nonlocal, which for C++ calls cp_lookup_symbol_nonlocal, which calls cp_lookup_symbol_namespace. But maybe this call is needed here for other callers of cp_lookup_symbol_namespace? The symbol lookup stuff is starting to feel spaghetti-ish to me. Jan> @@ -1121,11 +1120,20 @@ lookup_symbol_aux (const char *name, const struct block *block, Jan> if (sym != NULL) Jan> return sym; Jan> - /* Now search all static file-level symbols. Not strictly correct, Jan> - but more useful than an error. Do the symtabs first, then check Jan> - the psymtabs. If a psymtab indicates the existence of the Jan> - desired name as a file-level static, then do psymtab-to-symtab Jan> - conversion on the fly and return the found symbol. */ Jan> + return lookup_static_symbol_aux (name, domain); Jan> +} Jan> + Jan> +/* Now search all static file-level symbols. Not strictly correct, Jan> + but more useful than an error. Do the symtabs first, then check Jan> + the psymtabs. If a psymtab indicates the existence of the Jan> + desired name as a file-level static, then do psymtab-to-symtab Jan> + conversion on the fly and return the found symbol. */ Jan> + Jan> +struct symbol * Jan> +lookup_static_symbol_aux (const char *name, const domain_enum domain) Jan> +{ Jan> + struct objfile *objfile; Jan> + struct symbol *sym; I think you should leave that comment in the previous function and write a new comment for lookup_static_symbol_aux. Tom