From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-31715-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 21323 invoked by alias); 23 Apr 2008 10:09:44 -0000
Received: (qmail 21312 invoked by uid 22791); 23 Apr 2008 10:09:43 -0000
X-Spam-Check-By: sourceware.org
Received: from mail.ashling.com (HELO ashling.com) (62.77.186.162)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 10:09:19 +0000
Received: from Syam ([192.168.10.57]) 	by ashling.com (ashling.com [127.0.0.1]) 	(MDaemon PRO v9.6.5) 	with ESMTP id md50000997455.msg 	for <gdb@sourceware.org>; Wed, 23 Apr 2008 11:09:15 +0100
X-Spam-Processed: ashling.com, Wed, 23 Apr 2008 11:09:15 +0100 	(not processed: message from trusted or authenticated source)
X-MDRemoteIP: 192.168.10.57
X-Return-Path: jiju.george@nestgroup.net
X-Envelope-From: jiju.george@nestgroup.net
X-MDaemon-Deliver-To: gdb@sourceware.org
From: "Jiju George T" <jiju.george@nestgroup.net>
To: <gdb@sourceware.org>
Subject: clearing call stack when a new binary file is loaded
Date: Wed, 23 Apr 2008 11:30:00 -0000
Message-ID: <005101c8a52a$13f76910$390aa8c0@ashmicro.ashling.com>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MDAV-Processed: ashling.com, Wed, 23 Apr 2008 11:09:16 +0100
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/msg00197.txt.bz2

Hi,

=A0 We are developing a graphical embedded debugger based on GDB mi interfa=
ce.
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.=20

Steps to reproduce the issues:=20

  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
=20=20
=20
Is this GDB behaviour by design? Is there any mi interface to clear the
stack frame and update to the current $pc value?=20

Thanks,
Jiju George