From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2887 invoked by alias); 16 Mar 2004 19:13:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2879 invoked from network); 16 Mar 2004 19:13:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Mar 2004 19:13:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B3Jzp-0003SQ-7S; Tue, 16 Mar 2004 14:13:01 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com, Hans-Peter Nilsson Subject: Re: [CRIS] dwarf2 frame sniffer problem? Message-ID: <20040316191301.GA13244@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com, Hans-Peter Nilsson References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> <40508BD8.10802@axis.com> <20040311171139.GA17530@nevyn.them.org> <40518F6A.2080806@axis.com> <20040312153817.GA20055@nevyn.them.org> <40572AA8.5040406@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40572AA8.5040406@axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00358.txt.bz2 Message-ID: <20040319000900.rss05bWuWpOkzBXUj4xyBIv9CLTyzn6_cN2N5LTPuJw@z> On Tue, Mar 16, 2004 at 05:26:16PM +0100, Orjan Friberg wrote: > Daniel Jacobowitz wrote: > > > >I see that your GCC port uses textual prologues. As it happens, I just > >implemented dwarf generation for that mechanism (for Thumb), so I know > >how it's supposed to work. Here's your problem. First you have: > > > > /* FIXME: Slightly redundant calculation, as we do the same in > > pieces below. This offset must be the total adjustment of the > > stack-pointer. We can then def_cfa call at the end of this > > function with the current implementation of execute_cfa_insn, but > > that wouldn't really be clean. */ > > > > cfa_label = dwarf2out_cfi_label (); > > dwarf2out_def_cfa (cfa_label, cfa_reg, cfa_offset); > > > >but that label is at the beginning of the function, so this is > >incorrect. That's not what the CFA is at the beginning of the > >function. > > Would emitting that label *after* the prologue be an option (i.e. > leaving us without dwarf2 information while still in the prologue)? Nope. Then when you step into the prologue (i.e. "step over") unwind information will be incorrect. I recommend taking a look at the patch where I implemented this for Thumb, or at the m68k implementation. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer