From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7803 invoked by alias); 19 Mar 2003 15:24:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7780 invoked from network); 19 Mar 2003 15:24:42 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 19 Mar 2003 15:24:42 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3333C2B11; Wed, 19 Mar 2003 10:24:38 -0500 (EST) Message-ID: <3E788BB5.6010209@redhat.com> Date: Wed, 19 Mar 2003 15:24:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() References: <20030317193537.GA11288@nevyn.them.org> <3E7670F6.9060906@redhat.com> <20030318051348.GA19741@nevyn.them.org> <3E773325.8090001@redhat.com> <20030318155007.GA26362@nevyn.them.org> <3E775106.8030609@redhat.com> <20030318171124.GA27974@nevyn.them.org> <3E77574F.2010407@redhat.com> <20030318173814.GA28471@nevyn.them.org> <3E777FF9.10005@redhat.com> <20030319141142.GA20672@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00288.txt.bz2 >> True dwarf2 debug info or that .eh_frame stuff (i'm curious)? > > > Hmm, I thought it would write out .debug_frame without DWARF-2 but > peering at the GCC source I seem to be wrong again. So just .eh_frame. So using .eh_frame is along the same lines as using ia64's libunwind. .eh_frame just happens to be implemented using something very like dwarf2's unwind code. > In any case, we'll parse both, so I stand by my statement. We'll have > .eh_frame even without normal debug info. I think there needs to be separate eh-frame and cfi-frame but with a common implementation. That way the subtle, but important, differences are clear. >> For stabs to work, it needs FRAME_LOCALS_ADDRESS(); and >> FRAME_LOCALS_ADDRESS() relies on the prologue analyzer (since frame ID >> won't correspond to `frame-base') for the computation of the correct >> value; and that means unwinding the same frame two ways. Outch. > > > Yeah... > - if we have CFI use it to find the frame address. Does this > become the frame ID? > - if we have dwarf2 debug and CFI, then we don't need to do prologue > analysis; CFI should give us everything we need > - if we have stabs debug and CFI, then we do need to do prologue > analysis to get FRAME_LOCALS_ADDRESS > - if we have either kind of debug info and no CFI then we need to do > prologue analysis; for dwarf2 we'll also need to calculate the frame > base from DW_AT_frame_base in order to use it to find locals > > Is that about right? Yes. Try the following higher-level view of the problem: On the left is the unwinder. It exports methods to obtain the frame's ID and the registers. It can be implemented using CFA, EH, libunwind, prologue analysis, ...; and the implementation is selected based on the low-level unwind information, or lack there of. On the right is the local variable code and that needs a frame-base / frame-locals-address / .... It uses high-level debug info and unwound register values to compute that base. It can be implemented using dwarf2's frame_base, or prologue analysis (stabs), or ...; and the implementation is selected based on the frame's high-level debug info. The mess occures when the high-level RHS frame-locals-address starts assuming the flavour of the low-level LHS unwinder and, consequently, tries to directly exploit that knowledge. For instance, a RHS prologue based frame-locals-address assuming that the LHS is also prologue based, and hence, can directly access the LHS's prologue analysis cache. It can be `fixed' two ways: - refusing to allow that sharing of data, forcing the RHS frame-locals-address to re-analyze the prologue. - make it possible to tease out the prologue analysis object so that both the LHS and RHS can share it. I guess the second is it. Andrew