#ifndef NEWVFORK
return fork ();
#else
+ sigframe thisframe;
vfork_save *vf = get_vfork_val ();
char **esp, **pp;
__asm__ volatile ("movl %%esp,%0": "=r" (vf->vfork_esp):);
__asm__ volatile ("movl %%ebp,%0": "=r" (vf->vfork_ebp):);
for (pp = (char **)vf->frame, esp = vf->vfork_esp;
- esp <= vf->vfork_ebp + 1; pp++, esp++)
+ esp <= vf->vfork_ebp + 2; pp++, esp++)
*pp = *esp;
int res = cygheap->fdtab.vfork_child_dup () ? 0 : -1;
debug_printf ("%d = vfork()", res);
return res;
}
- cygheap->fdtab.vfork_parent_restore ();
-
vf = get_vfork_val ();
- __asm__ volatile ("movl %%esp,%0": "=r" (esp):);
for (pp = (char **)vf->frame, esp = vf->vfork_esp;
- esp <= vf->vfork_ebp + 1; pp++, esp++)
+ esp <= vf->vfork_ebp + 2; pp++, esp++)
*esp = *pp;
+ thisframe.init (mainthread);
+ cygheap->fdtab.vfork_parent_restore ();
+
if (vf->pid < 0)
{
int exitval = -vf->pid;
int pid = vf->pid;
vf->pid = 0;
+ sig_dispatch_pending ();
return pid;
#endif
}
seems to be "active", then a "pending" flag is set (see below) and the
function returns. Otherwise processing continues.
-After determining that sigsave is available, setup_handler will take
-one of two routes, depending on whether the main thread is executing
-in the cygwin DLL or is currently in "user" code. We'll discuss the
-cygwin DLL case first.
+After determining that sigsave is available, setup_handler will take one
+of two routes, depending on whether the main thread is executing in the
+cygwin DLL or is currently in "user" code. We'll discuss the cygwin DLL
+case first.
If sigsave seems to be available, then the frame information for the
main thread is inspected. This information is set by any cygwin
aware. It should detect when a signal has arrived and return
immediately.
-So, if mainframe is active, that means that we have good information about
-the state of the main thread. Cygwin uses the stack frame info from this
-structure to insert a call to the assembly language function 'sigdelayed'
-in place of the main thread's normal return address. So, when a call to
-(e.g.) _read returns after detecting a signal, it does not return to its
-caller. Rather, it returns to sigdelayed.
+So, if mainframe is active, that means that we have good information
+about the state of the main thread. Cygwin uses the stack frame info
+from this structure to insert a call to the assembly language function
+'sigdelayed' in place of the main thread's normal return address. So,
+when a call to (e.g.) _read returns after detecting a signal, it does
+not return to its caller. Rather, it returns to sigdelayed.
The sigdelayed function saves a lot of state on the stack and sets the
signal mask as appropriate for POSIX. It uses information from the
sigsave structure which has been filled in by interrupt_on_return, as
-called by setup_handler. sigdelayed pushes a "call" the function
+called by setup_handler. sigdelayed pushes a "call" to the function
"sigreturn" on the stack. This will be the return address seen by the
signal handler. After setting up the return value, modifying the signal
mask, and saving other information on the stack, sigreturn clears the
sigsave structure (so that setup_handler can use it) and jumps to the
-signal handler function.
-
-
+signal handler function. And, so a UNIX signal handler function is
+emulated.
+
+The signal handler function operates as normal for UNIX but, upon
+return, it does not go directly back to the return address of the
+original cygwin function. Instead it returns to the previously
+mentioned 'sigreturn' assembly language function.
+
+sigreturn resets the process mask to its state prior to calling the
+signal handler. It checks to see if any new signals have come in and
+calls the handler for them now, ensuring that the order of signal
+arrival is more or less maintained. It checks to see if a cygwin
+routine has set a special "restore this errno on returning from a
+signal" value and sets errno to this, if so. Finally, it restores all
+of the register values that were in effect when sigdelayed was called.
OSDN Git Service
