From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6457 invoked by alias); 19 Mar 2003 14:11:47 -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 6406 invoked from network); 19 Mar 2003 14:11:46 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 19 Mar 2003 14:11:46 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18vgBf-00076h-00; Wed, 19 Mar 2003 10:13:07 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18veIB-0005PL-00; Wed, 19 Mar 2003 09:11:43 -0500 Date: Wed, 19 Mar 2003 14:11:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: frame->unwind->this_base() Message-ID: <20030319141142.GA20672@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E777FF9.10005@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00287.txt.bz2 On Tue, Mar 18, 2003 at 03:22:17PM -0500, Andrew Cagney wrote: > >On Tue, Mar 18, 2003 at 12:28:47PM -0500, Andrew Cagney wrote: > > > >>>That would be a very bad assumption. They are pratically guarenteed to > > > >>>>be different. > > > >>> > >>> > >>>Then what do you mean by a "dwarf2 frame"? I'd assume you meant the > >>>CFA, but it sounds like you mean a frame for which we have dwarf2 > >>>.debug_info. > > > >> > >>A frame with debug info provided by dwarf2. CFI gives the register > >>info, location expressions give the variable info, ... > >> > >>What started out as a simple cfi-frame looks like it might need to > >>evolve into dwarf2-frame ... > > > > > >DWARF-2 debug info does not corelate with CFI info. For instance, GCC > >will generate DWARF-2 CFI with stabs debug info. It will also generate > >CFI with no debug info at all, or DWARF-2 info without any CFI (if > >requested). > > 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. In any case, we'll parse both, so I stand by my statement. We'll have .eh_frame even without normal debug info. > 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? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer