From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24070 invoked by alias); 25 Nov 2007 22:05:37 -0000 Received: (qmail 24062 invoked by uid 22791); 25 Nov 2007 22:05:36 -0000 X-Spam-Check-By: sourceware.org Received: from pool-70-20-17-24.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (70.20.17.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 25 Nov 2007 22:05:32 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id B1A942B352; Sun, 25 Nov 2007 17:05:30 -0500 (EST) Date: Sun, 25 Nov 2007 22:05:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling Message-ID: <20071125220530.GA10356@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4749C544.9050909@portugalmail.pt> User-Agent: Mutt/1.5.16 (2007-06-09) 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/msg00474.txt.bz2 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