From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2955 invoked by alias); 5 Mar 2007 13:17:00 -0000 Received: (qmail 2783 invoked by uid 22791); 5 Mar 2007 13:16:57 -0000 X-Spam-Check-By: sourceware.org Received: from 164.Red-80-36-45.staticIP.rima-tde.net (HELO jupiter.champenstudios.com) (80.36.45.164) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 Mar 2007 13:16:49 +0000 Received: from [192.168.1.132] ([192.168.1.132]) by jupiter.champenstudios.com (8.13.5/8.13.5) with ESMTP id l25DDfdP010666; Mon, 5 Mar 2007 14:13:41 +0100 Message-ID: <45EC1815.2000002@champenstudios.com> Date: Mon, 05 Mar 2007 13:17:00 -0000 From: Lerele User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) MIME-Version: 1.0 To: Pedro Alves 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> In-Reply-To: <45EB6AC8.3090307@portugalmail.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00038.txt.bz2 Pedro Alves wrote: > >>> I plan on eventually adding a third option to GenerateConsoleCtrlEvent >>> and DebugBreakProcess, that injects a thread into the debuggee, since >>> WinCE doesn't have any of the above. That should make every >>> stoppable process stoppable, in all Windows versions. >>> >> >> Do you find appropriate to use this method? > > > It is exactly what DebugBreakProcess does internally, so if you > have a problem with the approach, you shouldn't be using it :) > The thread is short-lived. It is something like: > > Well so it seems. :-) GenerateConsoleCtrlEvent seems to create a remote thread too. It's not only that I'm concerned about it, personally I just find it unacceptable for a debugger to do that kind of thing (or Windows anyway); user code (or standard windows dlls) can do plainly anything in DllEntry for instance, that can make debugged code behave very differently. 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. 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? > >> 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? > > > I was leaving something like this as a last resort, but should be > possible, > I guess. Would need extra logic to handle the fact that there isn't > any real breakpoint exception live (in resume, for instance). > Yes, but it would be something just internal to win32 low, gdbserver nor gdb should notice.