From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1715 invoked by alias); 17 Mar 2009 07:26:41 -0000 Received: (qmail 1702 invoked by uid 22791); 17 Mar 2009 07:26:40 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Mar 2009 07:26:36 +0000 Received: (qmail 27990 invoked from network); 17 Mar 2009 07:26:34 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Mar 2009 07:26:34 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: [1/3] broken -thread-info output in non-stop mode, suppress_stop_observer Date: Tue, 17 Mar 2009 07:29:00 -0000 User-Agent: KMail/1.11.90 (Linux/2.6.24-24-generic; KDE/4.2.65; i686; svn-936416; 2009-03-07) Cc: gdb-patches@sourceware.org References: <200903170621.02808.pedro@codesourcery.com> In-Reply-To: <200903170621.02808.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200903171026.31197.vladimir@codesourcery.com> 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: 2009-03/txt/msg00304.txt.bz2 On Tuesday 17 March 2009 09:21:02 Pedro Alves wrote: > This patch removes the suppress_stop_observer global. As indicated > in the comments I'm removing, this was problematic for non-stop > mode. > > To fix the broken -thread-info output mentioned here: > > http://sourceware.org/ml/gdb-patches/2009-03/msg00236.html > > ... I wanted to add a thread_info->in_infcall flag to use in > the 3rd patch in the series. That meant I needed to get rid of > the suppress_resume_observer global, which then brings > us to this. > > Vladimir, et al, how does this look? I did not look very carefully at details of conditions, but the general idea looks solid. One detail is the new command you add in infrun.c -- can it explicitly write down *why* we need to suppress *stopped at this point, when doing finish? Thanks, Volodya