From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15758 invoked by alias); 5 Mar 2007 20:44:24 -0000 Received: (qmail 15746 invoked by uid 22791); 5 Mar 2007 20:44:23 -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; Mon, 05 Mar 2007 20:44:16 +0000 Received: from localhost (localhost [127.0.0.1]) by elrond.portugalmail.pt (Postfix) with ESMTP id 1A7F239DED; Mon, 5 Mar 2007 20:41:18 +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 2pTo-nldI2Em; Mon, 5 Mar 2007 20:41:17 +0000 (WET) Received: from [127.0.0.1] (88.210.66.122.rev.optimus.pt [88.210.66.122]) (Authenticated sender: pedro_alves@portugalmail.pt) by elrond.portugalmail.pt (Postfix) with ESMTP id A1DE03A79B; Mon, 5 Mar 2007 20:11:54 +0000 (WET) Message-ID: <45EC7842.6020406@portugalmail.pt> Date: Mon, 05 Mar 2007 20:44: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: Lerele CC: 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> In-Reply-To: <45EC1815.2000002@champenstudios.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000721-1, 03-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/msg00047.txt.bz2 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? > Another problem besides one commented in my last message, is that signal > handlers will not be called in child, but is this really an issue when > doing a remote interrupt request? > You mean the ctrl-c event/SIGINT? I don't have much of an opinion here. I never needed it except for stopping the inferior, and WinCE doesn't have signals, 'ctrl-c events', or a proper console, for the matter. > >> >>> 1) May be solved by doing: >>> >>> 1. Create in gdbserver process as much threads as number of cpus -1 >>> the computer has. These threads should consume all scheduled cpu for >>> them. >>> 2. SetPriorityClass on gdbserver process with real-time priority. >>> 3. GetPriorityClass on child and store it to restore later on. >>> 4. SetPriorityClass on child with below normal or idle. >>> 5. Suspend all child threads. >>> Child should be stopped here. >>> >>> Only problem I see with this can be if child changes its own priority >>> class between steps 3 and 4 above, however this is a very remote >>> possibility, because if this happens it is because child is already >>> running in real-time priority, and in this case gdbserver possibly >>> may not even work at all (unless you run gdbserver itself with this >>> priority). >>> >>> What do you think about this? >> 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.) Cheers, Pedro Alves