From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16123 invoked by alias); 25 Nov 2007 15:00:56 -0000 Received: (qmail 16114 invoked by uid 22791); 25 Nov 2007 15:00:55 -0000 X-Spam-Check-By: sourceware.org Received: from gw.sprintaddict.net (HELO champenstudios.com) (80.91.89.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 25 Nov 2007 15:00:48 +0000 Received: from [192.168.1.5] (164.Red-80-36-45.staticIP.rima-tde.net [80.36.45.164]) (authenticated bits=0) by champenstudios.com (8.13.8/8.13.8) with ESMTP id lAPEr9Ce032335 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 25 Nov 2007 15:53:10 +0100 Message-ID: <47498E1A.5070101@champenstudios.com> Date: Sun, 25 Nov 2007 15:00:00 -0000 From: Lerele User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [gdbserver/win32] (4/11) New interrupting method References: <4737B553.2040302@portugalmail.pt> In-Reply-To: <4737B553.2040302@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: 2007-11/txt/msg00466.txt.bz2 Pedro Alves escribió: > Hi, > > Here is the new method to stop the inferior, based on a mix of > Leo's and mine patches. The idea is simple. Loop through all > the inferior threads suspending them. > > This version doesn't contain the gdbserver priority handling, > which means that there is a higher chance of the inferior > breaking the method, since the operation is not atomic. For > example by tweaking its own thread's priorities or if the > inferior is calling ResumeThread in its own threads while > gdbserver is stopping them. > > The next patch will minimize those chances, by elevating > gdbserver's priority while stopping the inferior with > this method. > > Leo, did I miss anything? > > Regtested on a local i686-pc-cygwin gdbserver. > > Cheers, > Pedro Alves > > > > I think this patch breaks interrupt functionality. The function suspend_one_thread in the new patch does not seem to retreive the thread context and sets the thread suspend count to 1, so the next call to thread_rec that should happen in gdbserver will get incorrect thread context. My interrupt patch I sent initially used thread_rec to pause the child threads, so get context should work here. I think it's more correct anyway to use thread_rec everywhere so that SuspendThread is centralized in one unique function. Is this correct, or is there something I may have slipped reading your patch? Leo.