From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15929 invoked by alias); 3 Dec 2007 03:54:22 -0000 Received: (qmail 15920 invoked by uid 22791); 3 Dec 2007 03:54:21 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.173) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Dec 2007 03:54:15 +0000 Received: by ug-out-1314.google.com with SMTP id h2so2011775ugf for ; Sun, 02 Dec 2007 19:54:15 -0800 (PST) Received: by 10.66.221.5 with SMTP id t5mr2783407ugg.1196654054229; Sun, 02 Dec 2007 19:54:14 -0800 (PST) Received: from ?78.130.100.26? ( [78.130.100.26]) by mx.google.com with ESMTPS id k30sm13425198ugc.2007.12.02.19.54.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 02 Dec 2007 19:54:14 -0800 (PST) Message-ID: <47537D21.4080206@portugalmail.pt> Date: Mon, 03 Dec 2007 03:54:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org, Lerele Subject: Re: [gdbserver/wince] (7/11) Make the new interrupt method actually always work in WinCE References: <4737B583.6040304@portugalmail.pt> <20071201190044.GF24231@caradoc.them.org> In-Reply-To: <20071201190044.GF24231@caradoc.them.org> 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-12/txt/msg00043.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Nov 12, 2007 at 02:08:03AM +0000, Pedro Alves wrote: >> So, what this patch does, is implement the same workaround MSFT's >> debugger uses. Don't set the context back to the inferior, unless >> it has been explicitly changed by gdb or gdbserver. Actually, it >> is a little bit better, as it won't crash if the user sets some >> register's contents back to what it was when the inferior stopped. > > This is all really nasty. Does this mean the register values we > report to GDB may actually change before the process stops? > Yes, unfortunatelly, but only on threads that are performing a syscall. I still haven't found a way around it, and the fact that MSFT's debugger has the same behaviour makes me believe there isn't one. The values we pass to gdb aren't that random. The registers seem to hold the values needed for a syscall, and are quite similar to what I see when I pause a process with MSFT's debugger. A syscall in WinCE ( < 6 at least ) is implemented by having the kernel sets things up for the thread to continue execution on a server process, outside kernel mode. I suspect that a SuspendThread will only have effect when the thread is running on the original process. If it is running on the server process, it will not stop until the kernel switches it back into the original process. >> 2007-11-12 Pedro Alves >> >> * win32-low.c (win32_get_thread_context) >> (win32_set_thread_context): New. >> (thread_rec): Use win32_get_thread_context. >> (continue_one_thread, win32_resume): Use win32_set_thread_context. >> * win32-low.h (win32_thread_info) [_WIN32_WCE]: Add `base_context' >> field. > > OK, I suppose. > Thanks, checked in. -- Pedro Alves