From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24023 invoked by alias); 4 Feb 2010 17:48:28 -0000 Received: (qmail 24014 invoked by uid 22791); 4 Feb 2010 17:48:27 -0000 X-SWARE-Spam-Status: No, hits=-2.5 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; Thu, 04 Feb 2010 17:48:22 +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 o14HmKdF013175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Feb 2010 12:48:20 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o14HmEU1003210; Thu, 4 Feb 2010 12:48:16 -0500 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 o14HmDr6002353; Thu, 4 Feb 2010 12:48:14 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 40E5837996D; Thu, 4 Feb 2010 10:48:13 -0700 (MST) From: Tom Tromey To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname References: <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> <20100201221905.GA15584@caradoc.them.org> <4B68B400.3030407@redhat.com> <20100203024553.GA22235@caradoc.them.org> Reply-To: tromey@redhat.com Date: Thu, 04 Feb 2010 17:48:00 -0000 In-Reply-To: <20100203024553.GA22235@caradoc.them.org> (Daniel Jacobowitz's message of "Tue, 2 Feb 2010 21:45:55 -0500") 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-02/txt/msg00126.txt.bz2 >>>>> "Daniel" == Daniel Jacobowitz writes: Daniel> I don't doubt that what you've got is correctly identifying and Daniel> handling GCC's output. But it does so by pattern matching on what GCC Daniel> currently emits, not by using tests that are sound according to the Daniel> standard. So with some future GCC, or some other non-GCC compiler, Daniel> it will probably fall down. Daniel> I don't believe that most of GCC's uses of DW_AT_specification are Daniel> required by the standard. And I don't think they're the only valid Daniel> uses of DW_AT_specification. So keying off whether that attribute is Daniel> present is too 'fuzzy' for me. I want to tie this back to the original code to see if I understand what part you are concerned about. >> + case DW_TAG_variable: >> + { >> + struct attribute *attr; >> + attr = dwarf2_attr (die, DW_AT_specification, cu); >> + if (attr) >> + return 1; Based on the above I am guessing it is the early return here? That is the only thing I could think of, because AFAICT this code generally respects what DWARF says. My understanding is that there are 2 cases. 1. If the variable is declared in the namespace scope, but defined outside, then a second defining DIE is emitted that refers to the declaration DIE using DW_AT_specification. In this case the declaration DIE's namespace is used. ... The code above seems to cheat a tiny bit because it unconditionally returns 1 in this case, whereas it should perhaps recurse. 2. If the variable is defined in the namespace scope, then no DW_AT_specification exists, and we use the DIE's parentage. The code gets this right. Daniel> I'm asking for you to either convince me that my assumptions in the Daniel> previous paragraph are incorrect, or to find some way that the Daniel> standard will support to answer the same query about the properties of Daniel> the DW_TAG_variable DIE. For instance, should we find the DIE's Daniel> logical location the same way determine_prefix does (parent, or Daniel> specification's parent) and then draw some conclusion based on Daniel> the type of the logical parent? >From what I can tell, die_needs_namespace is consistent with determine_prefix, with the caveat that it is is an approximation, due to the lack of recursion. It is more like "die_may_need_namespace". I'm still not understanding what problem you see, but I would like to. Tom