From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9898 invoked by alias); 4 Mar 2007 22:53:36 -0000 Received: (qmail 9886 invoked by uid 22791); 4 Mar 2007 22:53:36 -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; Sun, 04 Mar 2007 22:53:33 +0000 Received: from [192.168.1.132] ([192.168.1.132]) by jupiter.champenstudios.com (8.13.5/8.13.5) with ESMTP id l24MmYR8031616; Sun, 4 Mar 2007 23:48:37 +0100 Message-ID: <45EB4D5A.7070703@champenstudios.com> Date: Sun, 04 Mar 2007 22:53: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> In-Reply-To: <45E211A5.6080905@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/msg00026.txt.bz2 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. 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. > +static void > +win32_send_signal (int signo) > +{ > + if (signo == SIGINT) > > > And I agree that it doesn't look right. With my patch > installed, it turns to: > > +static void > +win32_send_signal (enum target_signal signo) > +{ > + if (signo == TARGET_SIGNAL_INT) > > Anyway, don't let this bother you. If it gets OKed as is, > I'll take care of it later. I changed it to: /* Send a signal to the inferior process, however is appropriate. */ static void win32_send_signal (int signo) { if (target_signal_from_host (signo) == TARGET_SIGNAL_INT) { 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. > Hi all, > > This patch adds support for sending OUTPUT_DEBUG_STRING_EVENT > messages to the controller gdb. Compared to the version found in > gdb/win32-nat.c, this handles Unicode messages, needed for > WinCE, but will not handle the special cygwin signal markers. That was the next thing I was going to do for win32 low. Nicely done. Thanks. :-) > Lerele wrote: > >> It works fine as it is, without making it too complex. >> > > Just tested it on Cygwin + XP Pro, and I could successfully stop a > running process. Nice. > > 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? Isn't there any other way to do it on WinCE? I say this because creating a single thread, either if you do it at child process creation, or at interrupt request, may make the child behave differently than when running it as a standalone (not being debugged). I mean, I don't know if this is really desired for gdbserver because doing this, memory layout for child may change, and when I debug a process that is buggy, say it crashes or whatever, I expect that when I debug the process, it will behave exactly the same way as when I run it without it being debugged, or at least as close as possible. A single memory allocation *may* affect a buggy child behavior and bypass the looked-for bug. As an alternative, may I suggest maybe doing a simple PauseThread for all threads in child? Win32 low already has synthetic thread pausing support and maybe this could be a fair solution. This would involve tricking gdb to think a real Win32 debug exception has occured, and control that situation within win32 low exclusively. The only problems I see with this is that 1) a child may suspend/resume threads (even though win32 docs say those functions are for debugger mainly), and this could interfere with stop procedure. 2) May affect timing, but anyway this already is affected by just running the child in multiprocess environment. 2) I guess is not really a problem. 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? 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. Leo.