From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27922 invoked by alias); 18 Jul 2007 15:38:17 -0000 Received: (qmail 27912 invoked by uid 22791); 18 Jul 2007 15:38:16 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_20,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Jul 2007 15:38:12 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6IFcAIq030146 for ; Wed, 18 Jul 2007 11:38:10 -0400 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6IFc91V015416; Wed, 18 Jul 2007 11:38:09 -0400 Received: from [172.16.14.55] (toner.toronto.redhat.com [172.16.14.55]) by pobox.toronto.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l6IFc9c4031669; Wed, 18 Jul 2007 11:38:09 -0400 Message-ID: <469E33E1.7080909@redhat.com> Date: Wed, 18 Jul 2007 15:38:00 -0000 From: Sami Wagiaalla User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Roland McGrath CC: frysk Subject: Re: Dwarf expertise needed References: <20070718090247.A712B4D05CF@magilla.localdomain> In-Reply-To: <20070718090247.A712B4D05CF@magilla.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00149.txt.bz2 Roland, First of all thank you for the thorough reply. I now see issues that I have not seen before. Roland McGrath wrote: >> What I am expecting it to return is the the scopes from narrowest to and >> including the scope corresponding to the concrete inlined instance, then >> the function within which it has been inlined and the scopes containing >> that; as per the dwarf spec. Is this a correct understanding of what the >> function /should/ do ? And should I fix the function, write a parallel >> one that does what i want, or is there another code pathway to get it ? >> > > I don't know why you call that "as per the dwarf spec". (The spec says > what the format means, not what any function does.) > I just meant to say "scope" in the dwarf spec sense, as opposed to lexical scope. [...] > Contemplating it now, I don't think it is really so quite confusing what's > required, at least for frame_base. I probably need to think more about the > nested function cases, and might confuse myself again doing it. I also > haven't thought of anything other than frame_base that a dwarf_getscopes > caller might need from a physically relevant but lexically disjoint DIE. > Something else I'm overlooking might have different requirements. To get > the right frame_base, I think a straightforward change of the getscopes > interface can cover it. As well as the array of lexical scope DIEs, it > would yield a parallel array of Dwarf_Die pointers. Each scope[i] > corresponds to base_scope[i]. Locations from scope[i] are resolved in the > physical context of base_scope[i]. For simple cases, scope[i]==base_scope[i]. > When scope[i] is an inlined_subroutine, base_scope[i] is the containing > subprogram that has the actual code. So, in all cases, base_scope[i] is > where you need to look for a frame_base attribute when scope[i] leads you to > a location that uses frame_base. > > But I'd like to try to think of other things than frame_base one might > need, and think through the nested function cases, before deciding what > exact change the interface should get. > That is cool. If it turns out that frame_base is the only instance then how about a function get_framebase that is smart enough to figure out where the correct frame base is. That way you help the client not make that mistake. Or get_* for each attribute that needs the abstract instance of the function. > Right now, if your test cases do not require the frame_base attribute, > then we can just work on fixing any bugs in the implementation of the > current definition of the dwarf_getscopes interface as I described it above. > > dwarf_getscopes has always been for the source-level semantic view of > lexical identifier scope. For other purposes, you might instead be > looking for the physical structural view of the compiled code. For > example, if you are displaying the running code in an inlined instance > and want to visualize "this code inlined into here", or are synthesizing > fictional call frames for a semantic backtrace including inlined calls. > (If you are only displaying the source location of the caller, you have > the call_{file,line,column} attributes at hand and don't need the > caller's DIE at all.) dwarf_getscopes_die does exactly this, though its > name and comments would lead you to think it acts like dwarf_getscopes > when given a DIE that is part of a concrete inlined instance tree. > (That's what it probably should do, and there should be a different call > for the simple structural visitor.) So with 0.128 code, you can use > dwarf_getscopes on a PC, then take a scope[i] of interest such as an > inlined_subroutine DIE, and pass it to dwarf_getscopes_die to see its > caller's scope context. > That will do, although I think there might be a bug there :(. Let me double check.