From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-55105-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 4269 invoked by alias); 11 Apr 2008 22:21:06 -0000
Received: (qmail 4254 invoked by uid 22791); 11 Apr 2008 22:21:05 -0000
X-Spam-Check-By: sourceware.org
Received: from mx2.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.25)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Apr 2008 22:20:37 +0000
Received: from kahikatea.snap.net.nz (23.31.255.123.static.snap.net.nz [123.255.31.23]) 	by viper.snap.net.nz (Postfix) with ESMTP id 6DD793D9E2A; 	Sat, 12 Apr 2008 10:20:29 +1200 (NZST)
Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) 	id 21DA78FC6D; Sat, 12 Apr 2008 10:20:28 +1200 (NZST)
From: Nick Roberts <nickrob@snap.net.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18431.58411.357257.512508@kahikatea.snap.net.nz>
Date: Fri, 11 Apr 2008 22:55:00 -0000
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Using bt command in async mode
In-Reply-To: <ftldhf$1v0$1@ger.gmane.org>
References: <18417.38670.195071.81191@kahikatea.snap.net.nz> 	<18418.37659.924305.827404@kahikatea.snap.net.nz> 	<ftldhf$1v0$1@ger.gmane.org>
X-Mailer: VM 7.19 under Emacs 22.2.50.1
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2008-04/txt/msg00229.txt.bz2

 > > Incidentally, the patch I've presented for bt isn't suitable for inclusion
 > > as it uses:
 > > 
 > > +
 > > +   if (restart)
 > > +     continue_command ("&", 0);
 > > 
 > > If the user interrupts with 'bt' during a step, he presumably wants the
 > > step to finish.  I'm not sure how easy it is for Gdb to jump the inferior
 > > back into it's old state of execution.
 > 
 > It's not very hard. You only need to hack continue_command not to call
 > (indirectly) the clear_proceed_status function, which currently wipes away
 > all state.

It looks a bit harder than that.  Perhaps the arguments proceed () was called
with need to be saved, as well as executing the appropriate contination
after proceed () returns.

-- 
Nick                                           http://www.inet.net.nz/~nickrob