From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3084 invoked by alias); 3 Nov 2010 02:55:47 -0000 Received: (qmail 3075 invoked by uid 22791); 3 Nov 2010 02:55:46 -0000 X-SWARE-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.windriver.com (HELO mail.windriver.com) (147.11.1.11) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 03 Nov 2010 02:55:40 +0000 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.windriver.com (8.14.3/8.14.3) with ESMTP id oA32tDN6014063; Tue, 2 Nov 2010 19:55:13 -0700 (PDT) Received: from ala-mail06.corp.ad.wrs.com ([147.11.57.147]) by ALA-MAIL03.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Nov 2010 19:55:13 -0700 Received: from [128.224.158.168] ([128.224.158.168]) by ala-mail06.corp.ad.wrs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Nov 2010 19:55:13 -0700 Message-ID: <4CD0CF42.8010203@windriver.com> Date: Wed, 03 Nov 2010 02:55:00 -0000 From: "Liu, Lei" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [PATCH] call cp_lookup_symbol_namespace recursively to search symbols in C++ base classes References: <4CCF89F0.5090100@windriver.com> <201011030009.47662.pedro@codesourcery.com> In-Reply-To: <201011030009.47662.pedro@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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-11/txt/msg00059.txt.bz2 On 2010年11月03日 08:09, Pedro Alves wrote: > Hi! > > I'm looking at this exact problem as well. :-) > >> 2010-11-02 Lei Liu >> >> * cp-namespace.c (cp_lookup_symbol_namespace): Recursively call >> itself to search C++ base classes. > >> @@ -513,6 +513,8 @@ cp_lookup_symbol_namespace (const char *scope, >> const domain_enum domain) >> { > ... >> @@ -530,6 +532,31 @@ cp_lookup_symbol_namespace (const char *scope, >> block = BLOCK_SUPERBLOCK (block); >> } >> >> + /* If scope is a C++ class, we need to search all its base classes. */ >> + if (scope == NULL || scope[0] == '\0') >> + return NULL; > > Your testcase is not hitting this empty scope check, due to your > "#include", which does namespace things, and > ends up emitting DW_TAG_namespace in the debug info, and > so dwarf2read.c sets the processing_has_namespace_info > global, and so a "namespace" for you test's class > is installed by: > > /* For C++, set the block's scope. */ > if (cu->language == language_cplus || cu->language == language_fortran) > cp_set_block_scope (new->name, block,&objfile->objfile_obstack, > determine_prefix (die, cu), > processing_has_namespace_info); > > If I remove that include from your test (and the printf), then > the patch no longer works. We need to do something here. Right. There is a problem here. It seems that we can't rely on the scope name as C++ class name since it may not be set in some cases. Is there any other way to get the class name from a block? If not, I think we need to set the scope regardless of value of processing_has_namespace_info. > > A related issue that should be addressed as well, I think, is: > > class A { > public: > enum E { X, Y, Z }; > }; > > A a; > > Both "print a.X" and "ptype a.X" should work. I've got a > patch that fixes this part, and a dejagnuified testcase, > but haven't sorted out the processing_has_namespace_info > part yet. > Thanks. Lei