This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: SML-NJ for CygWin32 Bugs/Problems


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@prospect.com.ru]
	Sent:	Tuesday, June 17, 1997 12:19 AM
	To:	gnu-win32@cygnus.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@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]