From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19615 invoked by alias); 10 Apr 2008 16:00:18 -0000 Received: (qmail 19603 invoked by uid 22791); 10 Apr 2008 16:00:18 -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; Thu, 10 Apr 2008 15:59:58 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JjzBn-0002Ux-Ur for gdb-patches@sources.redhat.com; Thu, 10 Apr 2008 15:59:52 +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 ; Thu, 10 Apr 2008 15:59:51 +0000 Received: from ghost by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Apr 2008 15:59:51 +0000 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [RFC] Using bt command in async mode Date: Thu, 10 Apr 2008 16:05:00 -0000 Message-ID: References: <18417.38670.195071.81191@kahikatea.snap.net.nz> <18418.37659.924305.827404@kahikatea.snap.net.nz> 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-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00200.txt.bz2 Nick Roberts wrote: > > Nick> This patch allows the bt to be executed in async mode while the > > Nick> inferior is executing. > > > > Nick> ! && strcmp (c->name, "interrupt") != 0 > > Nick> ! && strcmp (c->name, "bt") != 0) > > > > I've seen a couple patches recently that touch this conditional. > > > > What do you think of this? It moves the flag into the command object > > instead of hard-coding it into a big 'if'. > > Sure, the list will only get longer. In the long run it might be a good > idea to add an argument to add_cmd and related functions. > > 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. - Volodya