From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8766 invoked by alias); 5 Feb 2010 20:24:00 -0000 Received: (qmail 8758 invoked by uid 22791); 5 Feb 2010 20:23:59 -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; Fri, 05 Feb 2010 20:23:55 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o15KNsVg020419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 5 Feb 2010 15:23:54 -0500 Received: from [IPv6:::1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o15KNmEK019336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Feb 2010 15:23:53 -0500 Message-ID: <4B6C7E54.8080203@redhat.com> Date: Fri, 05 Feb 2010 20:24: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: <20100201164837.GF21339@caradoc.them.org> <4B672C38.60007@redhat.com> <20100201193941.GA17445@caradoc.them.org> <4B674D1B.5040209@redhat.com> <20100201221905.GA15584@caradoc.them.org> <4B68B400.3030407@redhat.com> <20100203024553.GA22235@caradoc.them.org> <20100204181358.GA27544@caradoc.them.org> <4B6C51BC.6040601@redhat.com> <20100205172352.GA16328@caradoc.them.org> In-Reply-To: <20100205172352.GA16328@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/msg00174.txt.bz2 On 02/05/2010 09:24 AM, Daniel Jacobowitz wrote: > Recursing to follow the specification makes sense. I don't think > recursing onto the parent makes sense though. Won't this cause > the wrong answer for: > > DW_TAG_subprogram > DW_TAG_variable > > ? If that doesn't matter, then I'm totally confused again :-) > That's your basic local variable. It might be a gcc-ism, but we actually get a DW_TAG_lexical_block between DW_TAG_subprogram and DW_TAG_variable. I presume this is to mark the prologue. It is a very nice way to know that a variable is not global. O:-) I can certainly understand why this is not such a desirable solution. But at least I now remember (or rather -- I am now reminded) why I originally wrote what I did for this (with DW_AT_external and checking the parent DIE's tag). After revisiting that, I think it clearer to understand if I invert the original test: case DW_TAG_variable: { struct attribute *attr; /* We only need to prefix "globally" visible variables. These include any variable marked with DW_AT_external or any variable that lives in a namespace. [Variables in anonymous namespaces require prefixing, but they are not DW_AT_external.] */ if (dwarf2_attr (die, DW_AT_specification, cu)) { struct dwarf2_cu *spec_cu = cu; return die_needs_namespace (die_specification (die, &spec_cu), spec_cu); } attr = dwarf2_attr (die, DW_AT_external, cu); if (attr || die->parent->tag == DW_TAG_namespace) return 1; return 0; } How does that look? Keith