From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27363 invoked by alias); 5 Feb 2010 17:29:47 -0000 Received: (qmail 27352 invoked by uid 22791); 5 Feb 2010 17:29:46 -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; Fri, 05 Feb 2010 17:29:41 +0000 Received: (qmail 12244 invoked from network); 5 Feb 2010 17:29:39 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Feb 2010 17:29:39 -0000 Date: Fri, 05 Feb 2010 17:29:00 -0000 From: Daniel Jacobowitz To: Keith Seitz Cc: gdb-patches@sourceware.org Subject: Re: [RFA 2/4] dwarf2_physname Message-ID: <20100205172352.GA16328@caradoc.them.org> Mail-Followup-To: Keith Seitz , gdb-patches@sourceware.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B6C51BC.6040601@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/msg00169.txt.bz2 On Fri, Feb 05, 2010 at 09:13:32AM -0800, Keith Seitz wrote: > I hadn't either. Next iteration in attached patch. > > BTW, while goofing around with the code a bit, it appears that since > I wrote all of this many, many months ago, things have changed (for > the better). physname_prefix and dependents are no longer necessary. > We can use determine_prefix instead. I apologize that I did not catch > this earlier. This version looks much nicer. I'm still confused about die_needs_namespace, but I think we're almost done. > + case DW_TAG_variable: > + 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); > + } > + > + return die_needs_namespace (die->parent, cu); 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. Otherwise, everything looks OK. -- Daniel Jacobowitz CodeSourcery