1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Copyright 2001, 2002, 2003, 2004 Red Hat Inc., Christopher Faylor
[note that the following discussion is still incomplete]
How do signals work?
On process startup, cygwin starts a secondary thread which deals with
signals. This thread contains a loop which blocks waiting for
information to arrive on a pipe whose handle (sendsig) is currently
stored in _pinfo (this may change).
Communication on the sendsig pipe is via the 'sigpacket' structure.
This structure is filled out by the sig_send function with information
about the signal being sent, such as (as of this writing) the signal
number, the originating pid, the originating thread, and the address of
the mask to use (this may change).
Any cygwin function which calls a win32 api function is wrapped by the
assembly functions "_sigfe" and "_sigbe". These functions maintain a
cygwin "signal stack" which is used by the signal thread to control
handling of signal interrupts. Cygwin functions which need to be
wrapped by these functions (the majority) are labelled by the SIGFE
option in the file cygwin.din.
The cygwin.din function is translated into a standard cygwin.def file by
the perl script "gendef". This function notices exported cygwin
functions which are labelled as SIGFE and generates a front end assembly
file "sigfe.s" which contains the wrapper glue necessary for every
function to call sigfe prior to actually dispatching to the real cygwin
function. This generated file contains low-level signal related
functions: _sigfe, _sigbe, sigdelayed, sigreturn, longjmp, and setjmp.
The signal stack maintained by sigfe/sigbe and friends is a secondary
shadow stack. Addresses from this stack are swapped into the "real"
stack as needed to control program flow. The intent is that executing
cygwin functions will still see the same stack layout as if they had
been called directly and will be able to retrieve arguments from the
stack but will always return to the _sigbe routine so that any signal
handlers will be properly called.
Upon receipt of a "non-special" (see below) signal, the function
sigpacket::process is called. This function determines what action, if
any, to take on the signal. Possible actions are: Ignore the signal
(e.g., SIGUSR1), terminate the program (SIGKILL, SIGTERM), stop the
program (SIGSTOP, SIGTSTP, etc.), wake up a sigwait or sigwaitinfo in a
targetted thread, or call a signal handler (possibly in a thread). If
no thread information has been sent to sigpacket::process, it determines
the correct thread to use based on various heuristics, as per UNIX. As
per linux, the only time a handler is called in a thread is when there
is some kind of fault like SIGSEGV, SIGILL, etc. Signals sent via the
UNIX kill() function are normally sent to the main thread. Ditto
signals sent as the result of pressing tty keys, like CTRL-C.
Signals which stop a process are handled by a special internal handler:
sig_handle_tty_stop. Some signals (e.g., SIGKILL, SIGSTOP) are
uncatchable, as on UNIX.
If the signal has an associated signal handler, then the setup_handler
function is eventually called. It is passed the signal, the address of
the handler, a standard UNIX sigaction structure, and a pointer to the
thread's "_cygtls" information. The meat of signal processing is in
setup_handler.
setup_handler has a "simple" task. It tries to stop the appropriate
thread and either redirect its execution to the signal handler function,
flag that a signal has been received (sigwait) or both (sigpause).
To accomplish its task, setup_handler first inspects the target thread's
local storage (_cygtls) structure. This structure contains information
on any not-yet-handled signals that may have been set up by a previous
call to setup_handler but not yet dispatched in the target thread. If this
structure seems to be "active", then setup_handler returns, notifying it's
parent via a false value. Otherwise processing continues.
(For pending signals, the theory is that the signal handler thread will
be forced to be rerun by having some strategic cygwin function call
sig_send with a __SIGFLUSH argument. This causes the signal handler to
rescan the signal array looking for pending signals.)
After determining that it's ok to send a signal, setup_handler will lock
the cygtls stack to ensure that it has complete access. It will then
inspect the thread's 'incyg' boolean. If this is true, the thread is
currently executing a cygwin function. If it is false, the thread is
unlocked and it is assumed that the thread is executing "user" code.
The actions taken by setup_handler differ based on whether the program
is executing a cygwin routine or not.
If the program is executing a cygwin routine, then the
interrupt_on_return function is called which causes the address of the
'sigdelayed' function to be pushed onto the thread's signal stack, and
the signal's mask and handler to be saved in the tls structure. After
performing these operations, the 'signal_arrived' event is signalled, as
well as any thread-specific wait event.
Since the sigdelayed function was saved on the thread's signal stack,
when the cygwin function returns, it will eventually return to the
sigdelayed "front end". The sigdelayed function will save a lot of
state on the stack and set the signal mask as appropriate for POSIX.
It uses information from the _cygtls structure which has been filled in
by interrupt_setup, as called by setup_handler. sigdelayed pushes a
"call" to the function "sigreturn" on the thread's signal stack. This
will be the return address eventually 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 signal number in the
_cygtls structure so that setup_handler can use it and jumps to the
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 a cygwin routine has set a special
"restore this errno on returning from a signal" value and sets errno to
this, if so. It pops the signal stack, places the new return address on
the real stack, restores all of the register values that were in effect
when sigdelayed was called, and then returns.
Ok. That is more or less how cygwin interrupts a process which is
executing a cygwin function. We are almost ready to talk about how
cygwin interrupts user code but there is one more thing to talk about:
SA_RESTART.
UNIX allows some blocking functions to be interrupted by a signal
handler and then return to blocking. In cygwin, so far, only
read/readv() and the wait* functions operate in this fashion. To
accommodate this behavior, a function notices when a signal comes in and
then calls the _cygtls function 'call_signal_handler_now'.
'call_signal_handler_now' emulates the behavior of both sigdelayed and
sigreturn. It sets the appropriate masks and calls the handler,
returning true to the caller if SA_RESTART is active. If SA_RESTART is
active, the function will loop. Otherwise it will typically return -1
and set the errno to EINTR.
Phew. So, now we turn to the case where cygwin needs to interrupt the
program when it is not executing a cygwin function. In this scenario,
we rely on the win32 "SuspendThread" function. Cygwin will suspend the
thread using this function and then inspect the location at which the
thread is executing using the win32 "GetThreadContext" call. In theory,
the program should not be executing in a win32 api since attempts to
suspend a process executing a win32 call can cause disastrous results,
especially on Win9x.
If the process is executing in an unsafe location then setup_handler
will (quickly!) return false as in the case above. Otherwise, the
current location of the thread is pushed on the thread's signal stack
and the thread is redirected to the sigdelayed function via the win32
"SetThreadContext" call. Then the thread is restarted using the win32
"ResumeThread" call and things proceed as per the sigdelayed discussion
above.
This leads us to the sig_send function. This is the "client side" part
of the signal manipulation process. sig_send is the low-level function
called by a high level process like kill() or pthread_kill().
** More to come **
|
