From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27599 invoked by alias); 6 Mar 2007 22:18:00 -0000 Received: (qmail 27591 invoked by uid 22791); 6 Mar 2007 22:18:00 -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; Tue, 06 Mar 2007 22:17:55 +0000 Received: from [192.168.1.132] ([192.168.1.132]) by jupiter.champenstudios.com (8.13.5/8.13.5) with ESMTP id l26ME9iW015517; Tue, 6 Mar 2007 23:14:10 +0100 Message-ID: <45EDE830.1080400@champenstudios.com> Date: Tue, 06 Mar 2007 22:18: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> <45EC1815.2000002@champenstudios.com> <45EC7842.6020406@portugalmail.pt> <45EDD148.3090200@portugalmail.pt> In-Reply-To: <45EDD148.3090200@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/msg00063.txt.bz2 Pedro Alves wrote: > Pedro Alves wrote: > >> What do you think of just suspending of thread, and setting a breakpoint >> at the current PC, and resuming? >> > > Errrh, don't even bother to answer this question. This method is of > course very > fallible. The thread may be blocked on IO or on a synchronization > object, which is > common in windows code (waiting for events). If the thread doesn't > get scheduled, > the breakpoint won't be hit. There may not be any thread that is a > got candidate > for the breakpoint - like if you have all your threads either deadlock > or blocked. > The beauty of injecting a remote thread, is that it stops all the > inferior threads atomically, > with minimum interference. That leaves: > Sorry for delay. Also there's the problem you said on WinCE about not being able to write memory (flash/rom...) > - ctrl-c event, which in some cases doesn't get through. > - DebugBreakProcess, on XP and 2003 Server and emulating it on NT < 5 > / Win9x/ME / CE > using code injection. One case where it could disturb the inferior > would be > when you can't debug a DllMain because of the CREATE_THREAD_EVENT that > this generates, or is there a way to inhibit its propagation? > - 'suspend all threads manually, but no breakpoint' method. > I'd just leave the last option. That's according with my personal preferences, for all advantages I wroite in previous messages. Does WinCe have available Set/GetPriorityClass, SetProcessAffinityMask, SuspendThread, ResumeThread? First two only work on some cases/win versions anyway. However, gdb win32-nat is already done with first option if I remember right, so maybe there's a preference to keep it that way. Also, about DllMain problem you say, I'd guess last option should also let you seamlessly debug DllMain without doing anything else (without having to disable breakpoints when doing an interrupt for instance --this would have to be done on client gdb side-- and even would introduce problems such as hitting a disabled-for-interrupt breakpoint when interrupt has not yet reached child). I find last option better almost however you look at it, unless there's some other problem I'm not seeing... maybe having a trillion threads running or something? Maybe writing down a pros/cons list could decide for itself. >> 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.) > > This is still my opinion. > I agree. Keep working code, and work on other option(s). Haven't had time to prepare the new patch. I hope I do will this week(end).