From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-31717-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 4799 invoked by alias); 23 Apr 2008 10:55:26 -0000
Received: (qmail 4790 invoked by uid 22791); 23 Apr 2008 10:55:25 -0000
X-Spam-Check-By: sourceware.org
Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 10:55:05 +0000
Received: from root by ciao.gmane.org with local (Exim 4.43) 	id 1Joccw-0008IS-BB 	for gdb@sources.redhat.com; Wed, 23 Apr 2008 10:55:02 +0000
Received: from 78.158.192.230 ([78.158.192.230])         by main.gmane.org with esmtp (Gmexim 0.1 (Debian))         id 1AlnuQ-0007hv-00         for <gdb@sources.redhat.com>; Wed, 23 Apr 2008 10:55:02 +0000
Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian))         id 1AlnuQ-0007hv-00         for <gdb@sources.redhat.com>; Wed, 23 Apr 2008 10:55:02 +0000
To: gdb@sources.redhat.com
From:  Vladimir Prus <vladimir@codesourcery.com>
Subject:  Re: clearing call stack when a new binary file is loaded
Date: Wed, 23 Apr 2008 12:54:00 -0000
Message-ID:  <fun4bj$voj$2@ger.gmane.org>
References:  <005101c8a52a$13f76910$390aa8c0@ashmicro.ashling.com>
Mime-Version:  1.0
Content-Type:  text/plain; charset=us-ascii
Content-Transfer-Encoding:  7Bit
User-Agent: KNode/0.10.5
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: 2008-04/txt/msg00199.txt.bz2

Jiju George T wrote:

> Hi,
> 
> We are developing a graphical embedded debugger based on GDB mi interface.
> UI part is based on Eclipse CDT and it communicates with GDB through mi
> interface. We are facing a problem with call stacks after a new binary is
> loaded to GDB. Our UI relays on the call stack information provided by GDB
> to show the debug context.
> 
> Steps to reproduce the issues:
> 
>   1) Start GDB and connect to remote GDB server which is connected to an
> embedded target. The embedded target is waiting at PC 0xBFC00000
>   2) Now load an ELF file to GDB with entry point as 0xA0000000
>   3) Now GDB shows $pc register value as 0xA0000000. But the call stack
> still shows frames with 0xBFC00000
>   
>  
> Is this GDB behaviour by design? Is there any mi interface to clear the
> stack frame and update to the current $pc value?

Which version of GDB?

- Volodya