From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8368 invoked by alias); 11 Mar 2004 15:55:40 -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 8213 invoked from network); 11 Mar 2004 15:55:37 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 11 Mar 2004 15:55:37 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2BFt48u029065; Thu, 11 Mar 2004 16:55:04 +0100 Message-ID: <40508BD8.10802@axis.com> Date: Thu, 11 Mar 2004 15:55:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> In-Reply-To: <405072FE.1010403@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00267.txt 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? -- Orjan Friberg Axis Communications From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8368 invoked by alias); 11 Mar 2004 15:55:40 -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 8213 invoked from network); 11 Mar 2004 15:55:37 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 11 Mar 2004 15:55:37 -0000 Received: from axis.com (ironmaiden.se.axis.com [10.13.8.120]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2BFt48u029065; Thu, 11 Mar 2004 16:55:04 +0100 Message-ID: <40508BD8.10802@axis.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org> <405072FE.1010403@axis.com> In-Reply-To: <405072FE.1010403@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00267.txt.bz2 Message-ID: <20040319000900.UbWW-oYBMJdQR6dqECesLJ-fGEEvtj93ZNRsQM1z9-c@z> 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? -- Orjan Friberg Axis Communications