From: Fuehrer AT seabase DOT com (Gary Fuehrer) Subject: RE: SML-NJ for CygWin32 Bugs/Problems 17 Jun 1997 18:33:09 -0700 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <6CC63E2E4FC1D011A2A700609716117A0E6DB1.cygnus.gnu-win32@seawolf> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Original-To: Sergey Okhapkin , gnu-win32 AT cygnus DOT com X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Original-Sender: owner-gnu-win32 AT cygnus DOT com I have the following understanding about CygWin32's signal handling support: 1. A thread causes an exception. 2. Win32 gets control, creates another thread, and starts the new thread running the exception handler. For CygWin32, this is the "__cygwin_exception_handler" function in "exceptions.cc". 3. The exception handler figures out what signal handler needs to be called and ultimately restarts the thread that excepted so that it begins by calling the signal handler. Assuming any of my understanding is correct, you see that a signal handler is running on the same thread that caused the exception. Therefore, for two reasons, it cannot use GetTreadContext to get the CPU/FPU state at the time the exception occurred. Nor can it call SetTreadContext to establish a CPU/FPU state upon returning. The first reason is obviously because the thread that caused the exception has continued running and Get/SetTreadContext can not return a thread's CPU/FPU state for some arbitrary time in the past. The other reason is that Get/SetThreadContext only works if the thread under investigation is first paused. Since the signal handler is running on the thread under investigation, it would have to pause itself, call Get/SetThreadContext, and start itself again. This certainly can't work. So, the cygwin exception handler needs to call GetTreadContext for the excepting thread before it is restarted to capture its CPU/FPU state at the time of the exception (it already does this, but doesn't get all the info it could). It then needs to pass this state information into the signal handler as a structure which the signal handler can optionally receive. The signal handler could then examine this structure and possibly make changes to it. In my case, I need to be able to change the instruction pointer register. After returning from the signal handler, the excepting thread would have to stop and let another thread get control so the changes made to the CPU/FPU state structure could be reflected in the excepting thread's state using SetThreadContext before it is re-started. Or something like that. I need to go read some Linux source code to see how Unix typically does signal handling so I know what I'm talking about. I'm just speculating at this point what must be going in Unix when a signal handler is called and returns. Gary -----Original Message----- From: Sergey Okhapkin [SMTP:sos AT prospect DOT com DOT ru] Sent: Tuesday, June 17, 1997 12:19 AM To: gnu-win32 AT cygnus DOT com; Gary Fuehrer Subject: RE: SML-NJ for CygWin32 Bugs/Problems Gary Fuehrer wrote: > 2. The signal handling in CygWin32 doesn't let me do the following: > a. Get and Set the "eip" register (or any register) of the > excepting thread. > b. Ascertain the kind of floating point exception that occurred. > The need is for "siginfo_t" and "sigcontext" parameters that can be > optionally received and modified by signal handlers. I noticed that > Sergey Okhapkin seems to have made it possible for a signal handler to > change the return address (equivalent to setting eip). This may work > for me, but I also need to get other registers like "edi" and the state > of the floating point processor. It seems like the extra optional > arguments technique is more traditional and more capable. > What unix analogs do you speak about? Win32 API allows to manipulate processor's registers with Get/SetThreadContext calls. -- Sergey Okhapkin, http://www.lexa.ru/sos Moscow, Russia Looking for a job. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".