From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9139 invoked by alias); 19 Mar 2003 15:32:27 -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 9123 invoked from network); 19 Mar 2003 15:32:26 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Mar 2003 15:32:26 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18vhRi-0007E2-00; Wed, 19 Mar 2003 11:33:46 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18vfYF-0005pv-00; Wed, 19 Mar 2003 10:32:23 -0500 Date: Wed, 19 Mar 2003 15:32:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() Message-ID: <20030319153223.GA22343@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <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> <3E788BB5.6010209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E788BB5.6010209@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00289.txt.bz2 On Wed, Mar 19, 2003 at 10:24:37AM -0500, Andrew Cagney wrote: > > >>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. What's your perception of the difference? Just based on the different on-disk format? The information contained is essentially the same. I certainly don't object, though. This will be painless. > >>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. I agree. Personally, what I would like would be to generate something structurally/conceptually equivalent to the unwind data from the prologue reader. This requires a bit of rewriting and a great deal of testing/patience. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer