From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26061 invoked by alias); 5 Mar 2007 00:56:56 -0000 Received: (qmail 26050 invoked by uid 22791); 5 Mar 2007 00:56:55 -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 00:56:53 +0000 Received: from localhost (localhost [127.0.0.1]) by elrond.portugalmail.pt (Postfix) with ESMTP id 874483A056; Mon, 5 Mar 2007 00:56: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 7brZ0OTHFjvJ; Mon, 5 Mar 2007 00:56:45 +0000 (WET) Received: from [127.0.0.1] (88.210.67.164.rev.optimus.pt [88.210.67.164]) (Authenticated sender: pedro_alves@portugalmail.pt) by elrond.portugalmail.pt (Postfix) with ESMTP id 0639A3A04F; Mon, 5 Mar 2007 00:56:42 +0000 (WET) Message-ID: <45EB6AC8.3090307@portugalmail.pt> Date: Mon, 05 Mar 2007 00:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 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> In-Reply-To: <45EB4D5A.7070703@champenstudios.com> Content-Type: multipart/mixed; boundary="------------020104010100000602060607" 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/msg00028.txt.bz2 This is a multi-part message in MIME format. --------------020104010100000602060607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 4508 Lerele wrote: > Pedro Alves wrote: > >> Space around '?' and ':'. Personally, I liked the res != FALSE ? 0 : >> -1 version better. >> >> >> Honestly, I don't really care too much. >> You guys decide. >> >> >> I don't care much either, but I think the spaces around '?' and ':' >> are mandatory. >> >> + return res ? 0 : -1; > > > I was wrong, res is not a Win32 BOOL, it's plainly a 0 or a 1. Then make it a BOOL, it makes the code clearer anyway. See attachment. > Already fixed spacing, while you were uploading your patches. > I'll send a new version for interrupt patch when I get some time to do > it, I'll need get latest cvs and merge my changes, then resend patch. > > I guess that would have been sufficient. But since you already changed > "target->send_signal" to "target->send_interrupt" I guess that is no > longer necessary. > Yep, just change it to win32_send_interrupt (void), and drop the if (sig == SIGINT) test. >> 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: //inferior's address space void helper_thread (void*) { DebugBreak (); // stops here. // and dies on resume. } // debugger's address space DebugBreakProcess (pid) { if (debugger_present) // we are sure of this // but this call can come from // a 3rd process. { create_remote_thread (helper_thread, pid); } } I stumbled on the fact that on WinCE there is no CreateRemoteThread. There is an undocumented but widely used PerformCallback4 that does a pretty good hack and can be used to simulate CreateRemoteThread (haven't tested yet), but it gone in WinCE >= 5, and I don't know the a replacement, that doesn't need messing with the registry to inject a dll into the inferior's address space, and start a thread on DllMain. Still searching. Maybe it is possible to stop one thread, and manually manipulate the stack to insert a call into CreateThread with DebugBreak as entry point. Although the prototype for DebugBreak is different from what CreateThread expects, there should be no problem, since WinCE is __cdecl. It may be problematic to do this is a thread blocked inside a Win32 or kernel call, or if the inferior thread chosen to do it is in a stack corrupted state. The advantage of these approaches is that there is a real breakpoint exception being thrown. Oh, you can't just insert a breakpoint at the current PC, since it may be a ROM address (real Flash/ROM, not locked pages). > Isn't there any other way to do it on WinCE? > Probably. I would like to know how other debuggers do it. > 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). > Does WinCE API have these required functions? > It may seem a quite odd way of doing it, but if it works, that's what > counts I think. > Don't know about WinCE > 5. The whole security model + address space model has changed. I'm still looking at a portable way across all WinCEs from Mobile 2003 to 6, and if I can simulate a DebugBreakProcess, it would all be nicely encapsulated. Thanks for the suggestions! Cheers, Pedro Alves --------------020104010100000602060607 Content-Type: text/plain; name="win32_attach" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="win32_attach" Content-length: 1338 Index: src/gdb/gdbserver/win32-i386-low.c =================================================================== --- src.orig/gdb/gdbserver/win32-i386-low.c 2007-03-03 19:52:56.000000000 +0000 +++ src/gdb/gdbserver/win32-i386-low.c 2007-03-05 00:01:52.000000000 +0000 @@ -673,7 +673,7 @@ win32_create_inferior (char *program, ch static int win32_attach (unsigned long pid) { - int res = 0; + BOOL res = FALSE; winapi_DebugActiveProcessStop *DebugActiveProcessStop = NULL; winapi_DebugSetProcessKillOnExit *DebugSetProcessKillOnExit = NULL; @@ -683,7 +683,7 @@ win32_attach (unsigned long pid) DebugSetProcessKillOnExit = (winapi_DebugSetProcessKillOnExit *) GetProcAddress (kernel32, _T("DebugSetProcessKillOnExit")); - res = DebugActiveProcess (pid) ? 1 : 0; + res = DebugActiveProcess (pid); if (!res) error ("Attach to process failed."); @@ -696,7 +696,7 @@ win32_attach (unsigned long pid) if (current_process_handle == NULL) { - res = 0; + res = FALSE; if (DebugActiveProcessStop != NULL) DebugActiveProcessStop (current_process_id); } @@ -707,7 +707,7 @@ win32_attach (unsigned long pid) if (kernel32 != NULL) FreeLibrary (kernel32); - return res? 0:-1; + return (res != FALSE) ? 0 : -1; } /* Handle OUTPUT_DEBUG_STRING_EVENT from child process. */ --------------020104010100000602060607--