From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23509 invoked by alias); 6 Mar 2007 00:04:39 -0000 Received: (qmail 23500 invoked by uid 22791); 6 Mar 2007 00:04:39 -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 00:04:37 +0000 Received: from localhost (localhost [127.0.0.1]) by elrond.portugalmail.pt (Postfix) with ESMTP id 421663A21C; Tue, 6 Mar 2007 00:01:38 +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 6WYVzbSXss69; Tue, 6 Mar 2007 00:01:37 +0000 (WET) Received: from [127.0.0.1] (62.169.92.162.rev.optimus.pt [62.169.92.162]) (Authenticated sender: pedro_alves@portugalmail.pt) by elrond.portugalmail.pt (Postfix) with ESMTP id 7A47E3A1A8; Tue, 6 Mar 2007 00:01:32 +0000 (WET) Message-ID: <45ECAFFC.4010700@portugalmail.pt> Date: Tue, 06 Mar 2007 00:04: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 000721-2, 05-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/msg00053.txt.bz2 Pedro Alves escreveu: > Lerele wrote: > >> It seems after all the solution proposed may be the best resort, >> instead of the last: more compatible, less interfereable with child, >> however a bit more difficult to write. >> In fact, the first version of interrupt code I wrote several months >> ago worked like that (I still keep a copy somewhere). It worked, but >> it was buggy, so I dropped it and wrote that other simpler new version. >> This other solution may be the one-for-all solution, because it uses >> rather more standard Win32 calls. > > The more I search for a *clean* way to do it in WinCE, the more I'm > inclined to drop the create_a_remote_thread idea. A bit of > googling and reading old MSFT docs indicates that older debuggers either > suspend all threads with SuspendThread (like you suggest, or get the > main thread's PC (EIP) and set a breakpoint there, which should be > simpler. (I would still have to do a little more work for WinCE > because the address might not be physically writable.) I think I > read somewhere that recent MSVC uses DebugBreakProcess, and hides the > fact > that the break was inside ntdll.dll, or wherever, by switching threads... > > What do you think of just suspending of thread, and setting a breakpoint > at the current PC, and resuming? > The GoVest debugger (*) uses something even simpler: - Suspend main thread, - Set single-step / trace flag (i386) - Resume thread (*) http://www.geocities.com/GoVest/ Cheers, Pedro Alves