From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-34281-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 7058 invoked by alias); 29 Apr 2009 17:01:16 -0000
Received: (qmail 6670 invoked by uid 22791); 29 Apr 2009 17:01:11 -0000
X-SWARE-Spam-Status: No, hits=0.7 required=5.0 	tests=AWL,BAYES_00,J_CHICKENPOX_13,J_CHICKENPOX_31,J_CHICKENPOX_33,J_CHICKENPOX_81,MSGID_MULTIPLE_AT,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (193.131.176.58)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 17:01:04 +0000
Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) 	by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id n3TH0wZm002757; 	Wed, 29 Apr 2009 18:00:58 +0100 (BST)
Received: from E101739 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); 	 Wed, 29 Apr 2009 18:00:58 +0100
From: "Anthony Berent" <anthony.berent@arm.com>
To: "'nagaraju.m'" <nagaraju.m@redpinesignals.com>, <gdb@sourceware.org>
References: <49F7EF2B.4090805@redpinesignals.com>
In-Reply-To: <49F7EF2B.4090805@redpinesignals.com>
Subject: RE: back trace issue
Date: Wed, 29 Apr 2009 18:29:00 -0000
Message-ID: <000101c9c8ec$0fa49090$2eedb1b0$@berent@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2009-04/txt/msg00215.txt.bz2

Nagaraju,

Based on my recent experience of debugging similar problems the "set debug
frame 1" command can be extremely useful in debugging this sort of problem
(although the output is not always easy to understand).

Also remember that gdb does lots of caching, so it will only work out the
stack the first time it needs it (probably before you enter the "bt"
command). To clear this out, so that you see how it is actually working out
the stack, you can use the "flushregs" command.

"info frame" will also tell you more about gdb's understanding of stack
frames than a simple backtrace.

- Anthony


-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf
Of nagaraju.m
Sent: 29 April 2009 07:10
To: gdb@sourceware.org
Subject: back trace issue

Hi,
    I am new to gdb. I am using  ported gdb to a specific target.
    when i am using back trace it is giving only the top most frame.

example:
    int add(int x,int y)
{
 int z;
 z=min(x,y);
 return z;
 }
int min(int p,int q)
{
 int r;
 r=max(p,q);
 return r;
 }
int max(int d,int e)
{
 return (d+e);
 }


int main()
{
int a, b, c,i;
a = 10;
b =20;
for(i=0;i<10;i++)
c = add(a,b);
return 0;
}

suppose if the control is in max function
(gdb) bt
#0  max (d=10, e=20) at abc.c:15
#1  0x20010348 in ?? ()

can you please  suggest me where to provide the information  to gdb so 
that "back trace" works properly.....

Thanks in advance,
Nagaraju