From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9131 invoked by alias); 6 Mar 2007 20:39:50 -0000 Received: (qmail 9123 invoked by uid 22791); 6 Mar 2007 20:39:48 -0000 X-Spam-Check-By: sourceware.org Received: from elrond.portugalmail.pt (HELO elrond.portugalmail.pt) (195.245.179.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 20:39:43 +0000 Received: from localhost (localhost [127.0.0.1]) by elrond.portugalmail.pt (Postfix) with ESMTP id 612D73A7BB; Tue, 6 Mar 2007 20:36:45 +0000 (WET) Received: from elrond.portugalmail.pt ([127.0.0.1]) by localhost (elrond.portugalmail.pt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYKEKH2u-bQ0; Tue, 6 Mar 2007 20:36:45 +0000 (WET) Received: from [127.0.0.1] (62.169.92.146.rev.optimus.pt [62.169.92.146]) (Authenticated sender: pedro_alves@portugalmail.pt) by elrond.portugalmail.pt (Postfix) with ESMTP id F09CD3AB13; Tue, 6 Mar 2007 20:35:39 +0000 (WET) Message-ID: <45EDD148.3090200@portugalmail.pt> Date: Tue, 06 Mar 2007 20:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Pedro Alves CC: Lerele , gdb-patches@sourceware.org Subject: Re: [Patch] Win32 gdbserver new interrupt support, and attach to process fix. References: <45DF7E27.10102@champenstudios.com> <45E211A5.6080905@portugalmail.pt> <45EB4D5A.7070703@champenstudios.com> <45EB6AC8.3090307@portugalmail.pt> <45EC1815.2000002@champenstudios.com> <45EC7842.6020406@portugalmail.pt> In-Reply-To: <45EC7842.6020406@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000722-0, 06-03-2007), Outbound message X-Antivirus-Status: Clean 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-03/txt/msg00059.txt.bz2 Pedro Alves wrote: > What do you think of just suspending of thread, and setting a breakpoint > at the current PC, and resuming? > Errrh, don't even bother to answer this question. This method is of course very fallible. The thread may be blocked on IO or on a synchronization object, which is common in windows code (waiting for events). If the thread doesn't get scheduled, the breakpoint won't be hit. There may not be any thread that is a got candidate for the breakpoint - like if you have all your threads either deadlock or blocked. The beauty of injecting a remote thread, is that it stops all the inferior threads atomically, with minimum interference. That leaves: - ctrl-c event, which in some cases doesn't get through. - DebugBreakProcess, on XP and 2003 Server and emulating it on NT < 5 / Win9x/ME / CE using code injection. One case where it could disturb the inferior would be when you can't debug a DllMain because of the CREATE_THREAD_EVENT that this generates, or is there a way to inhibit its propagation? - 'suspend all threads manually, but no breakpoint' method. > What about using the version you sent (if approved), and then work on > this new version on top? IMHO, it is better to have something working > first. (I don't believe the extra thread makes a difference > 99.999999999% > of the times.) This is still my opinion. Cheers, Pedro Alves