From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 865 invoked by alias); 25 Nov 2007 22:13:29 -0000 Received: (qmail 855 invoked by uid 22791); 25 Nov 2007 22:13:29 -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 22:13:23 +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 lAPM5jQL002421 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Nov 2007 23:05:46 +0100 Message-ID: <4749F37F.8090003@champenstudios.com> Date: Sun, 25 Nov 2007 22:13:00 -0000 From: Lerele User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling References: <4053daab0711211019r15f3a862g677080b65b4d8e71@mail.gmail.com> <4744BCCE.60705@portugalmail.pt> <20071123010744.GA31180@ednor.casa.cgf.cx> <4746A922.30404@champenstudios.com> <20071124053341.GA4214@ednor.casa.cgf.cx> <474832C2.7030307@champenstudios.com> <20071124204828.GB4928@ednor.casa.cgf.cx> <47498A4F.3050101@champenstudios.com> <20071125181316.GB7689@ednor.casa.cgf.cx> <4749C544.9050909@portugalmail.pt> <20071125220530.GA10356@ednor.casa.cgf.cx> In-Reply-To: <20071125220530.GA10356@ednor.casa.cgf.cx> 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/msg00477.txt.bz2 Christopher Faylor escribió: > On Sun, Nov 25, 2007 at 06:56:04PM +0000, Pedro Alves wrote: > >> Christopher Faylor wrote: >> >>> On Sun, Nov 25, 2007 at 03:44:31PM +0100, Lerele wrote: >>> >>>> What do you think? >>>> >>> There is some code in win32-nat.c which was a result of my uncertainty >>> about the Windows debugging API. I thought that since we have a couple >>> more eyes on this now someone might know a bit more about how this >>> works. Understanding the foundations is never a bad idea. >>> I'm not interested in gdbserver or what you think may be happening in >>> the future. If the SuspendThread/ResumeThread code can be eliminated >>> from win32-nat.c along with all of the bookkeeping that is required to >>> avoid races then it may be a good idea to do so. Whether it is a good >>> idea in light of future enhancements is a decision I can make but, >>> personally, I rarely see a good reason to keep code complication around >>> for the future unless someone is actually planning to do the work. >>> We can stop talking about this now since it is apparent that no one >>> actually knows the answer to my question. >>> >> 100% Agreed. >> >> Just to let you know that I plan on looking at this. >> I'm specifically wanting to look at what we're doing >> when/if we need to step over something with all >> threads but the current stopped -- if that is supposed to >> happen, it looks like we're broken, we should be >> suspending all the threads but the current before >> resuming. >> > > I was going to try just temporarily doing this to see what happens: > > #define SuspendThread(hThread) 1 > #define ResumeThread(hThread) 1 > > cgf > > I did remove SuspendThread from gdbserver, before my last reply. Did have to remove SuspendThreadInterrupt support too. Worked Ok. I guess win32-nat.c should be similar.