From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10083 invoked by alias); 23 Jun 2008 18:22:33 -0000 Received: (qmail 10070 invoked by uid 22791); 23 Jun 2008 18:22:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jun 2008 18:22:14 +0000 Received: (qmail 761 invoked from network); 23 Jun 2008 18:22:12 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Jun 2008 18:22:12 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] win32-nat.c 'set new-console' and interruption Date: Mon, 23 Jun 2008 19:24:00 -0000 User-Agent: KMail/1.9.9 References: <000001c8d330$0c6b51f0$2541f5d0$@u-strasbg.fr> <200806231541.26276.pedro@codesourcery.com> <20080623173620.GA10962@ednor.casa.cgf.cx> In-Reply-To: <20080623173620.GA10962@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806231922.10798.pedro@codesourcery.com> 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-06/txt/msg00395.txt.bz2 A Monday 23 June 2008 18:36:20, Christopher Faylor wrote: > On Mon, Jun 23, 2008 at 03:41:26PM +0100, Pedro Alves wrote: > >Another option is to use SuspendThread on all threads to stop the > >process, which is what I believe Visual Studio uses. gdbserver has > >that implemented for systems that don't have DebugBreakProcess. > > It may be ok in Windows XP and beyond (I haven't checked) but I don't > believe you can reliably use SuspendThread otherwise. If you suspend a > thread at the wrong point you can cause problems. It may have been a problem with earlier Windows versions (maybe deadlocking on some global internal lock, but evidence is scarse). Not sure it's a real problem. Would pretty much make it useless if you can't use it from a debugger. google is riddled with articles claiming not to use it, but those are aimed at application developers who confuse it with a locking primitive. I don't believe that when WaitForDebugEvent returns with all threads stopped, there has been any kind of special magic done that SuspendThread wouldn't trigger. Sure, it is dangerous to use SuspendThreads to suspend threads in the current process (as some stack walking libs do), as the deadlock risk is higher then, like deadlocking on output or painting routines; but that is a non-issue for a debugger. I know for sure MSFT's Windows CE debugger (I bet it's the same codebase as the desktop debugger) uses SuspendThread to stop the process, as enabling its debug output tells the whole world. :-) I did notice that it was GetThreadContext that seemed to do the blocking waiting for the thread to suspend in user-code (and noticed other weirdnesses around that, that seemed CE specific). I know you've been all over this before, but for the archives: Quoting from MSDN: "If the function succeeds, execution of the specified thread is suspended and the thread's suspend count is incremented. Suspending a thread causes the thread to stop executing *user-mode* (application) code." "This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. (...)" I sure hope we can use it if/when we get to implement non-stop mode for Windows. Anyway, back to the original issue: do we really need to translate that SIGTRAP into a SIGINT (from a DebugBreakProcess) ? -- Pedro Alves