From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5068 invoked by alias); 14 Feb 2004 14:52:09 -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 5060 invoked from network); 14 Feb 2004 14:52:08 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.170.238) by sources.redhat.com with SMTP; 14 Feb 2004 14:52:08 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EFEE12B97; Sat, 14 Feb 2004 09:52:02 -0500 (EST) Message-ID: <402E3612.50001@gnu.org> Date: Sat, 14 Feb 2004 14:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Orjan Friberg Cc: gdb-patches@sources.redhat.com, Michael Elizabeth Chastain , Joel Brobecker Subject: Re: CRIS port; frame cleanup crash References: <3F392591.4050409@redhat.com> <402BCCF2.601@axis.com> <402BDCDF.5040506@gnu.org> <402E24DC.8060006@axis.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00364.txt.bz2 [Joel, MichaelC, FYI] > 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. Yes, "pc" is a misnomer, within GDB it doesn't mean the "pc register", "resume address" is closer. Check the comments in frame.c:struct frame_info for definitions of: "next", "inner", "newer" and separatly "prev", "outer", "older". Yes, link register is the return address register. This frame (the caller) calls next frame (the callee). As part of that the callers resume addresses ends up in the callee's return-address register. The callee (next) then saves the return-address register on the stack. Hence to get the callers (this) PC, it needs to be dug out of the callers (next) frame's stack. Anyway, sounds like you've got it right. > 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? Exactly that. Also "advance.exp", in particular the sequence: ./gdb advance (gdb) break func (gdb) run (gdb) advance func3 --- should break in main and not func3 is a good check of the frame ID. And callfuncs.exp, and a sequence like: ./gdb callfuncs (gdb) break add (gdb) break main (gdb) run (gdb) print add(1,2) (gdb) bt (gdb) print add(3,4) (gdb) bt add(3,4) add (1,2) main () (gdb) is a good check of dummy frames > 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? Towards the end. It's good to first get the old code working reasonably well. Andrew