From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4565 invoked by alias); 29 Apr 2009 16:01:52 -0000 Received: (qmail 4426 invoked by uid 22791); 29 Apr 2009 16:01:50 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 16:01:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id CE79B2BAB61; Wed, 29 Apr 2009 12:01:42 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AxpV4LsTbZIL; Wed, 29 Apr 2009 12:01:42 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9D1FC2BABC3; Wed, 29 Apr 2009 12:01:42 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 85CE8F5924; Wed, 29 Apr 2009 09:01:37 -0700 (PDT) Date: Wed, 29 Apr 2009 17:01:00 -0000 From: Joel Brobecker To: "nagaraju.m" Cc: gdb@sourceware.org Subject: Re: back trace issue Message-ID: <20090429160137.GE23979@adacore.com> References: <49F7EF2B.4090805@redpinesignals.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49F7EF2B.4090805@redpinesignals.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00214.txt.bz2 > can you please suggest me where to provide the information to gdb so > that "back trace" works properly..... Typically, the [...]-tdep file for your architecture will provide a set of routines that compute the value of a register in the caller's frame (aka the "previous" frame) given a struct frame_info and and its associated frame cache. Have a look at some of the -tdep.c files, and search for "_prev_register", or "_this_id". That should give you a few leads. I'll also mention that there is a new module in prologue-value.[hc] that can simplify your job when doing prologue analysis. I am mentioning it because it's relatively use a still little used. Also, if your target supports DWARF, you might also want to see if the they produce CFI info, in which case a DWARF-based unwinder would be able to compute your backtrace without requiring the prologue analyzer. I can't remember the names of the routines but you'll need to provide a gdbarch routine that converts a dwarf register number into the associated GDB register number. And then hook in the dwarf unwinder sniffers: dwarf2_append_unwinders. Again, have a look at the various -tdep files. -- Joel