From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20101 invoked by alias); 14 Feb 2004 13:38:42 -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 20093 invoked from network); 14 Feb 2004 13:38:41 -0000 Received: from unknown (HELO miranda.se.axis.com) (193.13.178.2) by sources.redhat.com with SMTP; 14 Feb 2004 13:38:41 -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 i1EDcanI006030; Sat, 14 Feb 2004 14:38:37 +0100 Message-ID: <402E24DC.8060006@axis.com> Date: Sat, 14 Feb 2004 13:38:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Andrew Cagney CC: gdb-patches@sources.redhat.com Subject: Re: CRIS port; frame cleanup crash References: <3F392591.4050409@redhat.com> <402BCCF2.601@axis.com> <402BDCDF.5040506@gnu.org> In-Reply-To: <402BDCDF.5040506@gnu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00363.txt.bz2 Andrew Cagney wrote: > > The term "unwind" is used by the dwarf-2 specification. > http://www.eagercon.com/dwarf/dwarf3std.htm > it includes a working example in the appendix. Excellent, thanks a lot. Section 6.4 regarding Call Frame Information cleared up some of the confusion regarding unwinding. > The important thing is to "dig out" the register from the correct frame. > frame_unwind_register (next_frame, "pc") will "dig out" the PC from the > next frame (often found in next frame's link register) returning the > value as it should be in "this_frame". This explanation has me slightly puzzled. I gather from the code that "PC" refers to the current program location within a frame, and not an actual CPU register. Is "next" synonymous with "outer" in your explanation above? (Perhaps a stupid question; maybe unwind by definition works on the outer frame/caller.) And "link register" I assume is the equivalent of a subroutine return pointer. Approaching it from another direction, what would be a good test to see if the unwind code works correctly? At present, step (into function calls), next (over function calls), finish, and backtrace seem to work ok for both leaf- and non-leaf-functions (for CRIS the prologue differs slightly as the SRP isn't pushed in case of a leaf function). Is there any particular existing testcase that would be good at detecting errors in the frame code? Another question: should I hook in the dwarf-2 frame sniffer from the very beginning? Or wait until the other stuff seems to be working ok? Thanks, Orjan -- Orjan Friberg Axis Communications