From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18894 invoked by alias); 1 Feb 2010 22:19:25 -0000 Received: (qmail 18880 invoked by uid 22791); 1 Feb 2010 22:19:24 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Feb 2010 22:19:13 +0000 Received: (qmail 9606 invoked from network); 1 Feb 2010 22:19:11 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Feb 2010 22:19:11 -0000 Date: Mon, 01 Feb 2010 22:19:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname Message-ID: <20100201221905.GA15584@caradoc.them.org> Mail-Followup-To: Keith Seitz , gdb-patches@sourceware.org References: <4B576983.2090808@redhat.com> <20100126211733.GA17877@caradoc.them.org> <4B609019.1090807@redhat.com> <4B61F20B.7070908@redhat.com> <20100128202429.GA29835@caradoc.them.org> <4B622047.7020503@redhat.com> <20100201164837.GF21339@caradoc.them.org> <4B672C38.60007@redhat.com> <20100201193941.GA17445@caradoc.them.org> <4B674D1B.5040209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B674D1B.5040209@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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-02/txt/msg00032.txt.bz2 On Mon, Feb 01, 2010 at 01:52:27PM -0800, Keith Seitz wrote: > For this code, gcc will output a type-like information DIE tree, > telling us ONLY about the composition of the anonymous namespace with > namespace G and variable Xg. Later gcc gives us a DIE with > DW_AT_location (to continue my (poor) type analogy: an instance of > the variable). To describe this DIE, we also get DW_AT_specification > and nothing more. Just DW_AT_location and DW_AT_specification. > > If we do not follow DW_AT_specification, dwarf2_physname will put the > variable Xg in the global namespace instead of "(anonymous > namespace)::G::Xg", which is where it really is defined. Right. The issue is not the presence or absence of the DW_AT_specification; the issue is whether to follow this DIE's parents, or its specification's parents. The reader handles this in a couple of other places already. For instance, see the comment in determine_prefix. I think this code has evolved a couple of times since the referenced block was added. Certainly all callers of the old pdi_needs_namespace are removed; the callers of die_needs_namespace are new. It may no longer be right. What're we trying to answer? For instance, is it the distinction between local variables and global variables? This is interesting because I believe that function-local classes get the enclosing function as a prefix, but obviously function-local automatic variables should not. Judging from some examples, you can not distinguish function local and function static variables without decoding DW_AT_location. But that's not the most important case; we don't need to qualify function local variables in the symbol table and things will work out OK. I'm not sure how DW_TAG_member comes into this either, that doesn't entirely make sense for non-static class members. Be careful about this one: GCC sometimes incorrectly uses DW_TAG_variable, when the DWARF standard says they should be DW_TAG_member. -- Daniel Jacobowitz CodeSourcery