Mail Archives: cygwin/1997/08/29/20:56:30
> Sergey Okhapkin wrote:
>
> ----------
> From: Sergey Okhapkin[SMTP:sos AT prospect DOT com DOT ru]
> Sent: Sunday, August 24, 1997 12:09 AM
> To: 'gnu-win32 AT cygnus DOT com'; Gary Fuehrer
> Cc: 'Geoffrey Noer'
> Subject: RE: SML-NJ for CygWin32
>
> 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 have a patch for exception.cc in winsup to add this functionality
> and
> > fix a related bug.
>
> I hope you made modifications in call_handler() and wrap assembly
> code?
> Current sources contains all you need to implement this
> functionality:
>
(Body of call_handler() here...)
> The saved integer registers are accessible from signal handler. Save
> float
> context just near pusha/pushf and modify sigarg/sigfunc/oldmask
> offsets.
>
I turns out that technique won't quite work. The exceptions that I need
to handle start in "__cygwin_exception_handler" such as "integer divide
by zero". But the current source for "call_handler" is only good for
dispatching events starting in "ctrl_c_handler". For Beta 18, someone
mistakenly thought that having "__cygwin_exception_handler" call
"ctrl_c_handler" for its implementation would be a good idea. While it
was a good idea to have a common signal dispatcher, the current
"call_handler" can't dispatch both kinds of events. The reason is that
"call_handler" assumes the current thread is not the excepting thread;
one of the first things "call_handler" does is it suspends the excepting
thread. But for any event starting in "__cygwin_exception_handler", the
current thread is the excepting thread. Consequently, "call_handler"
never dispatches and never returns for events like "integer divide by
zero".
So, yes, I made modifications to call_handler() and the wrap assembly
code to get things to work. But it's not worth sharing for these
reasons:
1. My patch is an awful kludge on top of a mistake.
2. I didn't take the time yet to provide the second and third arguments
to signal handlers for events that start in "ctrl_c_handler".
3. The second and third arguments that I'm passing to the signal
handlers do not conform to POSIX.4 which it should and which wouldn't be
hard to do.
I'd be glad to make exceptions.cc a correct, POSIX.4 compliant signal
dispatcher. But to do it, I need the correct versions of exceptions.cc
and signal.cc to start from. The Beta 18 starting point that I have now
is missing the new beta 19 stuff and the Sergey Okhapkin patches. How
can we coordinate this effort?
> > > > 3. There is no SIGVTALRM signal.
> > SML-NJ doesn't seem to need this in order to function. For now, I'm
> > providing a dummy #define.
>
> I don't know how to implement virtual timer on win32.
>
According to Geoffrey Noer, setitimer() and getitimer() are implemented
in beta 19. If I understand it correctly, that is the virtual timer and
therefore SIGVTALRM will be available.
> > > > 4. "L_ctermid" is not defined (but "L_cuserid" is).
> > I don't remember why SML-NJ needs this. For now, I'm providing a
> dummy
> > #define. It's not critical.
>
> L_ctermid define should be added to stdio.h, and ctermid() call should
> be
> added to winsup sources for POSIX conformance.
>
That's the way I see it, too. Even a stub for ctermid() would be
helpful for beta 19.
> > > > 5. The following definitions are not in the Posix sockets
> include
> > > > files (only the Windows socket stuff)
>
> The missing defines already added to headers.
>
Which ones? Beta 19? Or one of your patches?
> --
> 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".
- Raw text -