From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16568 invoked by alias); 1 Feb 2010 21:52:40 -0000 Received: (qmail 16558 invoked by uid 22791); 1 Feb 2010 21:52:39 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS 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; Mon, 01 Feb 2010 21:52:33 +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 o11LqWLk019894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Feb 2010 16:52:32 -0500 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o11LqRSN025976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Feb 2010 16:52:31 -0500 Message-ID: <4B674D1B.5040209@redhat.com> Date: Mon, 01 Feb 2010 21:52:00 -0000 From: Keith Seitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Lightning/1.0pre Thunderbird/3.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname References: <20091222192444.GB15339@caradoc.them.org> <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> In-Reply-To: <20100201193941.GA17445@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-02/txt/msg00031.txt.bz2 On 02/01/2010 11:39 AM, Daniel Jacobowitz wrote: > DW_AT_specification is present for many variables in namespaces > (at least in current GCC output). But what significance does it > actually have? Can you explain the check above in terms of the DWARF > standard? If not, I don't think it's right. I don't know if what gcc is doing is proper DWARF or not, but I don't see any indication on reading the DWARF3 spec that it is. If I may use namespace.exp as an example: namespace { namespace G { int Xg; }; }; 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. > DW_AT_specification just says that there is a specification of this > variable in another DIE. The same variable could be written with > or without it. In the case where DW_AT_specification is omitted, the physname information is contained within the DIE's immediate ancestry. I would expect to see, e.g., DW_TAG_namespace -- DW_AT_name -- DW_TAG_namespace -- DW_AT_name -- DW_TAG_variable -- DW_AT_name -- DW_AT_location as opposed to (the below is what we actually get from gcc) DW_TAG_namespace -- DW_AT_name -- DW_TAG_namespace -- DW_AT_name -- DW_TAG_variable -- DW_AT_name ... DW_AT_variable -- DW_AT_specification (points to DW_TAG_variable above) -- DW_AT_location Keith