From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20529 invoked by alias); 11 Mar 2004 17:11:41 -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 20504 invoked from network); 11 Mar 2004 17:11:40 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Mar 2004 17:11:40 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B1Tie-00075U-1R; Thu, 11 Mar 2004 12:11:40 -0500 Date: Thu, 11 Mar 2004 17:11:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? Message-ID: <20040311171139.GA17530@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> <40508BD8.10802@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40508BD8.10802@axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00271.txt On Thu, Mar 11, 2004 at 04:55:04PM +0100, Orjan Friberg wrote: > I don't know if this is related to the previous suggested problem (i.e. > the dwarf2 information being wrong), but I changed the test program > slightly to: > > void bar(void) {} > void foo(void) > { > bar(); > } > int main () > { > foo(); > return 0; > } > > Now foo is no longer a leaf function, and thus saves the return address > on the stack in its prologue. Stepping over foo ("next" in main) causes > a breakpoint to be set at the first instruction in foo. After the > target is stopped at that instruction (which is where the return address > is pushed on the stack) dwarf2_frame_prev_register is called, which > thinks that the PC is saved on the stack (case > DWARF2_FRAME_REG_SAVED_OFFSET) and reads it from there. Obviously the > value it reads is wrong, since the return address hasn't been pushed yet. > > What's wrong here? Is the dwarf2 debug information wrong, or should > dwarf2_frame_prev_register not have been called while still in the prologue? The beauty of using the CFI data is that it _is_ supposed to work in the prologue. It sounds like the CFI is wrong. Could you post both assembly and CFI data for the same testcase? I don't know CRIS assembly but I imagine I can interpret it well enough to see what's going on. It also sounds like your DWARF2_REG_TO_REGNUM may need work, if the unwinder thinks r16 is the return address column and GDB thinks it's an 8-bit register. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20529 invoked by alias); 11 Mar 2004 17:11:41 -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 20504 invoked from network); 11 Mar 2004 17:11:40 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Mar 2004 17:11:40 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B1Tie-00075U-1R; Thu, 11 Mar 2004 12:11:40 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Orjan Friberg Cc: gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? Message-ID: <20040311171139.GA17530@nevyn.them.org> Mail-Followup-To: Orjan Friberg , gdb-patches@sources.redhat.com References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> <40508BD8.10802@axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40508BD8.10802@axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00271.txt.bz2 Message-ID: <20040319000900.tweCP1hjlvsk9O2xJpY1MgE2WGVQm6YG2ajjXh0U2jE@z> On Thu, Mar 11, 2004 at 04:55:04PM +0100, Orjan Friberg wrote: > I don't know if this is related to the previous suggested problem (i.e. > the dwarf2 information being wrong), but I changed the test program > slightly to: > > void bar(void) {} > void foo(void) > { > bar(); > } > int main () > { > foo(); > return 0; > } > > Now foo is no longer a leaf function, and thus saves the return address > on the stack in its prologue. Stepping over foo ("next" in main) causes > a breakpoint to be set at the first instruction in foo. After the > target is stopped at that instruction (which is where the return address > is pushed on the stack) dwarf2_frame_prev_register is called, which > thinks that the PC is saved on the stack (case > DWARF2_FRAME_REG_SAVED_OFFSET) and reads it from there. Obviously the > value it reads is wrong, since the return address hasn't been pushed yet. > > What's wrong here? Is the dwarf2 debug information wrong, or should > dwarf2_frame_prev_register not have been called while still in the prologue? The beauty of using the CFI data is that it _is_ supposed to work in the prologue. It sounds like the CFI is wrong. Could you post both assembly and CFI data for the same testcase? I don't know CRIS assembly but I imagine I can interpret it well enough to see what's going on. It also sounds like your DWARF2_REG_TO_REGNUM may need work, if the unwinder thinks r16 is the return address column and GDB thinks it's an 8-bit register. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer