此文只簡(jiǎn)單分析發(fā)送信號(hào)給用戶程序后，用戶堆棧和內(nèi)核堆棧的變化。沒(méi)有分析實(shí)時(shí)信號(hào)，當(dāng)然整個(gè)過(guò)程基本一致。很多參考了＜情景分析＞，所以有些代碼和現(xiàn)在的內(nèi)核可能不同，比如RESTORE_ALL，但大體的機(jī)制是類似的。
1. 一個(gè)信號(hào)小例子
hex@Gentoo ~/signal $ cat sigint.c
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
void sig_int(int signo)
{
printf("hello\n");
}
int main()
{
if(signal(SIGINT, sig_int) == SIG_ERR){
printf("can't catch SIGINT\n");
exit(-1);
}
for(;;)
;
return 0;
}
2. 用戶堆棧里發(fā)生的故事
2.1 編譯運(yùn)行該程序,并設(shè)置斷點(diǎn)在sig_int函數(shù)開(kāi)頭(0x80482e8)，并設(shè)置SIGINT信號(hào)的處理方式
hex@Gentoo ~/signal $ gdb ./sigint
(gdb) b *0x80482e8
Breakpoint 1 at 0x80482e8: file sigint.c, line 6.
(gdb) handle SIGINT noprint pass
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) y
Signal Stop Print Pass to program Description
SIGINT No No Yes Interrupt
(gdb) r
Starting program: /home/gj/signal/sigint
2.2 向該程序發(fā)送信號(hào): kill -INT 此程序的pid號(hào)
hex@Gentoo ~/signal $ kill -INT 4639
2.3 該程序收到信號(hào)后停在斷點(diǎn)處
Breakpoint 1, sig_int (signo=2) at sigint.c:6
6 {
(gdb) i r esp
esp 0xbfffe7ec 0xbfffe7ec
(gdb) x/40a 0xbfffe7ec
0xbfffe7ec: 0xb7fff400 0x2 0x33 0x0
0xbfffe7fc: 0x7b 0x7b 0x8048930 <__libc_csu_init> 0x80488f0 <__libc_csu_fini>
0xbfffe80c: 0xbfffed58 0xbfffed40 0x0 0x0
0xbfffe81c: 0xbfffec18 0x0 0x0 0x0
0xbfffe82c: 0x8048336 <main+58> 0x73 0x213 0xbfffed40
0xbfffe83c: 0x7b 0xbfffead0 0x0 0x0
0xbfffe84c: 0x0 0x0 0x0 0x0
0xbfffe85c: 0x0 0x0 0x0 0x0
0xbfffe86c: 0x0 0x0 0x0 0x0
0xbfffe87c: 0x0 0x0 0x0 0x0
棧上的內(nèi)容為信號(hào)棧sigframe：
根據(jù)此結(jié)構(gòu)可以知道：
1). 返回地址0xb7fff400，它指向
vdso里的sigreturn
(gdb) x/10i 0xb7fff400
0xb7fff400 <__kernel_sigreturn>: pop %eax
0xb7fff401 <__kernel_sigreturn+1>: mov $0x77,%eax
0xb7fff406 <__kernel_sigreturn+6>: int $0x80
這個(gè)地址根據(jù)內(nèi)核的不同而不同，我的內(nèi)核版本是2.6.38。
2). 信號(hào)處理程序完成后，會(huì)回到 eip = 0x8048336 的地址繼續(xù)執(zhí)行。
2.4 執(zhí)行完sig_int函數(shù)后，進(jìn)入了__kernel_sigreturn，接著回到了代碼0x8048336處，一切恢復(fù)了正常。
(gdb) x/5i $pc
=> 0x8048336 <main+58>: jmp 0x8048336 <main+58>
(gdb) i r esp
esp 0xbfffed40 0xbfffed40
在用戶層我們能看到的只有上面這么多信息了，可能有一個(gè)地方不能理解：在上面過(guò)程c中 從0xbfffe7ec起那一塊棧上的內(nèi)容從哪來(lái)的？（正常情況下堆棧esp應(yīng)該一直指向在過(guò)程d中顯示的esp值0xbfffed40）
現(xiàn)在來(lái)看看在上面這些現(xiàn)象之下，內(nèi)核的堆棧發(fā)生了怎樣的變化。
3. 內(nèi)核堆棧里發(fā)生的故事
3.1 發(fā)信號(hào)時(shí)
在 2.2 里當(dāng)執(zhí)行kill -INT 4639后，pid為4639的程序（也就是我們運(yùn)行的 ./sigint）會(huì)收到一個(gè)信號(hào)，但是信號(hào)實(shí)際都是在內(nèi)核里實(shí)現(xiàn)的。每個(gè)進(jìn)程（這里只講進(jìn)程的情況，線程類似，線程有一個(gè)tid）都有一個(gè)pid，與此pid對(duì)應(yīng)有一個(gè)結(jié)構(gòu) task_struct ，在task_struct里有一個(gè)變量 struct sigpending pending，當(dāng)該進(jìn)程收到信號(hào)時(shí)，并不會(huì)立即作出反應(yīng)，只是讓內(nèi)核把這個(gè)信號(hào)記在了此變量里（它里面是一個(gè)鏈表結(jié)構(gòu)）。當(dāng)然，此時(shí)與內(nèi)核堆棧還沒(méi)有多大關(guān)系。
3.2 檢測(cè)信號(hào)
如果只記錄了信號(hào)，但沒(méi)有相應(yīng)反應(yīng)，那有什么用啊。一個(gè)進(jìn)程在什么 情況下會(huì)檢測(cè)信號(hào)的存在呢？在<情景分析>里說(shuō)到了：“在中斷機(jī)制中，處理器的硬件在每條指令結(jié)束時(shí)都要檢測(cè)是否有中斷請(qǐng)求的存在。信號(hào)機(jī)制是純軟件的，當(dāng)然不能依靠硬件來(lái)檢測(cè)信號(hào)的到來(lái)。同時(shí)，要在每條指令結(jié)束時(shí)都來(lái)檢測(cè)顯然是不現(xiàn)實(shí)的，甚至是不可能的。所以對(duì)信號(hào)的檢測(cè)機(jī)制是：每當(dāng)從系統(tǒng)調(diào)用，中斷處理或異常處理返回到用戶空間的前夕；還有就是當(dāng)進(jìn)程被從睡眠中喚醒（必定是在系統(tǒng)調(diào)用中）的時(shí)候，此時(shí)若發(fā)現(xiàn)有信號(hào)在等待就要提前從系統(tǒng)調(diào)用返回。總而言之，不管是正常返回還是提前返回，在返回到用戶空間的前夕總是要檢測(cè)信號(hào)的存在并作出反應(yīng)。”
因此，對(duì)收到的信號(hào)做出反應(yīng)的時(shí)間是 從內(nèi)核返回用戶空間的前夕，那么有那些情況會(huì)讓程序進(jìn)入內(nèi)核呢？答案是中斷，異常和系統(tǒng)調(diào)用。簡(jiǎn)單了解一下它們發(fā)生時(shí)內(nèi)核堆棧的變化。
//-----中斷，異常，系統(tǒng)調(diào)用 : 開(kāi)始
1)在用戶空間發(fā)生中斷時(shí)，CPU會(huì)自動(dòng)在內(nèi)核空間保存用戶堆棧的SS， 用戶堆棧的ESP， EFLAGS, 用戶空間的CS, EIP, 中斷號(hào) - 256
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP | 中斷號(hào) － 256
進(jìn)入內(nèi)核后，會(huì)進(jìn)行一個(gè)SAVE_ALL，這樣內(nèi)核棧上的內(nèi)容為：
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP | 中斷號(hào) － 256 | ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX
好了，一切都處理完時(shí)，內(nèi)核jmp到RESTORE_ALL（它是一個(gè)宏，例：在x86_32體系結(jié)構(gòu)下，/usr/src/kernel/arch/286/kernel/entry_32.S文件里包含該宏的定義）
RESTORE做的工作，從它的代碼里就可以看出來(lái)了：
首先把棧上的 ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX pop到對(duì)應(yīng)的寄存器里
然后將esp ＋ 4 把 “中斷號(hào) － 256” pop掉
此時(shí)內(nèi)核棧上的內(nèi)容為：
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP
最后執(zhí)行iret指令，此時(shí)CPU會(huì)從內(nèi)核棧上取出SS, ESP, ELFGAS, CS, EIP，然后接著運(yùn)行。
2) 在用戶空間發(fā)生異常時(shí)，CPU自動(dòng)保存在內(nèi)核棧的內(nèi)容為：
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP | 出錯(cuò)代碼 error_code
（注：CPU只是在進(jìn)入異常時(shí)才知道是否應(yīng)該把出錯(cuò)代碼壓入堆棧（為什么?），而從異常處理通過(guò)iret指令返回時(shí)已經(jīng)時(shí)過(guò)境遷，CPU已經(jīng)無(wú)從知當(dāng)初發(fā)生異常的原因，因此不會(huì)自動(dòng)跳過(guò)這一項(xiàng)，而要靠相應(yīng)的異常處程序?qū)Χ褩＜右哉{(diào)整，使得在CPU開(kāi)始執(zhí)行iret指令時(shí)堆棧頂部是返回地址）
進(jìn)入內(nèi)核后，沒(méi)有進(jìn)行SAVE_ALL，而是進(jìn)入相應(yīng)的異常處理函數(shù)（這個(gè)函數(shù)是包裝后的，真正的處理函數(shù)在后面）（在此函數(shù)里會(huì)把真正的處理函數(shù)的地址push到棧上），然后jmp到各種異常處理所共用的程序入口error_code，它會(huì)像SAVE_ALL那樣保存相應(yīng)的寄存器（沒(méi)有保存ES），此時(shí)內(nèi)核空間上的內(nèi)容為：
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP | 出錯(cuò)代碼 error_code | 相應(yīng)異常處理函數(shù)入口 | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX
（注：如果沒(méi)有出錯(cuò)代碼，則此值為0）
最后結(jié)束時(shí)與中斷類似（RESTORE_ALL）。
3) 發(fā)生系統(tǒng)調(diào)用時(shí)，CPU自動(dòng)保存在內(nèi)核棧的內(nèi)容為:
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP
為了與中斷和異常的棧一致，在進(jìn)入系統(tǒng)調(diào)用入口（ENTRY(system_call)）后會(huì)首先push %eax，然后進(jìn)行SAVE_ALL，此時(shí)內(nèi)核棧上的內(nèi)容為
| 用戶堆棧的SS | 用戶堆棧的ESP | EFLAGS | 用戶空間的CS | EIP | EAX | ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX
最后結(jié)束時(shí)與中斷類似（RESTORE_ALL）。
//-----中斷，異常，系統(tǒng)調(diào)用 : 結(jié)束
中斷，異常，系統(tǒng)調(diào)用這部分有一點(diǎn)遺漏的地方：檢測(cè)信號(hào)的時(shí)機(jī)就是緊挨著RESTORE_ALL之前發(fā)生的。
3.3 對(duì)檢測(cè)到的信號(hào)做出反應(yīng)
如果檢測(cè)到有要處理的信號(hào)時(shí)，就要開(kāi)始做一些準(zhǔn)備工作了，此時(shí)內(nèi)核里的內(nèi)容為（進(jìn)入內(nèi)核現(xiàn)場(chǎng)時(shí)的內(nèi)容）
| 用戶堆棧的SS1 | 用戶堆棧的ESP1 | EFLAGS1 | 用戶空間的CS1 | EIP1 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1
（注：？的值有三個(gè)選擇：中斷號(hào) － 256／出錯(cuò)代碼 error_code／出錯(cuò)代碼 error_code）
假設(shè)將要處理的信號(hào)對(duì)應(yīng)的信號(hào)處理程序是用戶自己設(shè)置的，即本文中SIGINT對(duì)應(yīng)的信號(hào)處理程序sig_int。
現(xiàn)在要做的事情是讓cpu去執(zhí)行信號(hào)處理程序sig_int，但是執(zhí)行前需要做好準(zhǔn)備工作：
3.3.1 setup_frame
在用戶空間設(shè)置好信號(hào)棧(struct sigframe)(假設(shè)設(shè)置好棧后esp的值為sigframe_esp，在本文中其值為0xbfffe7ec)，即在2.3里看到的棧內(nèi)容。
注：struct sigframe里至少包含以下內(nèi)容：
用戶堆棧的SS1， 用戶堆棧的ESP1， EFLAGS1， 用戶空間的CS1， EIP1， ES1， DS1， EAX1， EBP1， EDI1， ESI1， EDX1， ECX1， EBX1
3.3.2 設(shè)置即將運(yùn)行的eip的值為信號(hào)處理函數(shù)sig_int的地址（為0x80482e8），并設(shè)置用戶ESP的值為sigframe_esp(為0xbfffe7ec)，這是通過(guò)修改內(nèi)核棧里的EIP和ESP的值實(shí)現(xiàn)的，因?yàn)樵趶南到y(tǒng)調(diào)用里iret時(shí)，會(huì)從內(nèi)核棧里取EIP，ESP。
這時(shí)內(nèi)核棧的內(nèi)核為:
| 用戶堆棧的SS1 |
0xbfffe7ec | EFLAGS1 | 用戶空間的CS1 |
0x80482e8 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1
最后，進(jìn)行RESTORE_ALL，內(nèi)核棧上的內(nèi)容為：
| 用戶堆棧的SS1 | 0xbfffe7ec | EFLAGS1 | 用戶空間的CS1 | 0x80482e8
RESTORE_ALL里執(zhí)行完iret后，寄存器內(nèi)容為： EIP為0x80482e8(即sig_int),esp為0xbfffe7ec 。 于是用戶空間到了步驟 2.3
3.4 信號(hào)處理程序完成以后
2.3 -> 2.4，進(jìn)入了sig_return系統(tǒng)調(diào)用，在sig_return里，內(nèi)核棧的內(nèi)容為（每個(gè)名字后面加一個(gè)2以便與前面的1區(qū)分）
| 用戶堆棧的SS2 | 用戶堆棧的ESP2 | EFLAGS2 | 用戶空間的CS2 | EIP2 | ? | ES2 | DS2 | EAX2 | EBP2 | EDI2 | ESI2 | EDX2 | ECX2 | EBX2
sig_return要做的主要工作就是根據(jù)用戶棧里sigframe的值修改內(nèi)核棧里的內(nèi)容，使內(nèi)核棧變?yōu)?
| 用戶堆棧的SS1 | 用戶堆棧的ESP1 | EFLAGS1 | 用戶空間的CS1 | EIP1 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1
至此內(nèi)核棧里的內(nèi)容和進(jìn)行信號(hào)處理前一樣了。經(jīng)過(guò)RESTORE_ALL后，用戶堆棧里的內(nèi)容也和以前一樣（主要指ESP的值一樣）。
"kill -INT 4639" 只是一段小插曲。程序從原處開(kāi)始運(yùn)行。