此文只簡(jiǎn)單分析發(fā)送信號(hào)給用戶(hù)程序后，用戶(hù)堆棧和內(nèi)核堆棧的變化。沒(méi)有分析實(shí)時(shí)信號(hào)，當(dāng)然整個(gè)過(guò)程基本一致。很多參考了＜情景分析＞，所以有些代碼和現(xiàn)在的內(nèi)核可能不同，比如RESTORE_ALL，但大體的機(jī)制是類(lèi)似的。

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. 用戶(hù)堆棧里發(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

在用戶(hù)層我們能看到的只有上面這么多信息了，可能有一個(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)程的情況，線(xiàn)程類(lèi)似，線(xià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)用，中斷處理或異常處理返回到用戶(hù)空間的前夕；還有就是當(dāng)進(jìn)程被從睡眠中喚醒（必定是在系統(tǒng)調(diào)用中）的時(shí)候，此時(shí)若發(fā)現(xiàn)有信號(hào)在等待就要提前從系統(tǒng)調(diào)用返回。總而言之，不管是正常返回還是提前返回，在返回到用戶(hù)空間的前夕總是要檢測(cè)信號(hào)的存在并作出反應(yīng)。”

  因此，對(duì)收到的信號(hào)做出反應(yīng)的時(shí)間是 從內(nèi)核返回用戶(hù)空間的前夕，那么有那些情況會(huì)讓程序進(jìn)入內(nèi)核呢？答案是中斷，異常和系統(tǒng)調(diào)用。簡(jiǎn)單了解一下它們發(fā)生時(shí)內(nèi)核堆棧的變化。

  //-----中斷，異常，系統(tǒng)調(diào)用 : 開(kāi)始
   1)在用戶(hù)空間發(fā)生中斷時(shí)，CPU會(huì)自動(dòng)在內(nèi)核空間保存用戶(hù)堆棧的SS， 用戶(hù)堆棧的ESP， EFLAGS, 用戶(hù)空間的CS, EIP, 中斷號(hào) - 256
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的CS | EIP | 中斷號(hào) － 256
   進(jìn)入內(nèi)核后，會(huì)進(jìn)行一個(gè)SAVE_ALL，這樣內(nèi)核棧上的內(nèi)容為：
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的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)容為：
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的CS | EIP
   最后執(zhí)行iret指令，此時(shí)CPU會(huì)從內(nèi)核棧上取出SS, ESP, ELFGAS, CS, EIP，然后接著運(yùn)行。

   2) 在用戶(hù)空間發(fā)生異常時(shí)，CPU自動(dòng)保存在內(nèi)核棧的內(nèi)容為：
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的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)容為：
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的CS | EIP | 出錯(cuò)代碼 error_code | 相應(yīng)異常處理函數(shù)入口 | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX
   （注：如果沒(méi)有出錯(cuò)代碼，則此值為0）

   最后結(jié)束時(shí)與中斷類(lèi)似（RESTORE_ALL）。

   3) 發(fā)生系統(tǒng)調(diào)用時(shí)，CPU自動(dòng)保存在內(nèi)核棧的內(nèi)容為:
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的CS | EIP
   為了與中斷和異常的棧一致，在進(jìn)入系統(tǒng)調(diào)用入口（ENTRY(system_call)）后會(huì)首先push %eax，然后進(jìn)行SAVE_ALL，此時(shí)內(nèi)核棧上的內(nèi)容為
   | 用戶(hù)堆棧的SS | 用戶(hù)堆棧的ESP | EFLAGS | 用戶(hù)空間的CS | EIP | EAX | ES | DS | EAX | EBP | EDI | ESI | EDX | ECX | EBX
 
   最后結(jié)束時(shí)與中斷類(lèi)似（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)容）
  | 用戶(hù)堆棧的SS1 | 用戶(hù)堆棧的ESP1 | EFLAGS1 | 用戶(hù)空間的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)處理程序是用戶(hù)自己設(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
  在用戶(hù)空間設(shè)置好信號(hào)棧(struct sigframe)(假設(shè)設(shè)置好棧后esp的值為sigframe_esp，在本文中其值為0xbfffe7ec)，即在2.3里看到的棧內(nèi)容。
  注：struct sigframe里至少包含以下內(nèi)容：
  用戶(hù)堆棧的SS1， 用戶(hù)堆棧的ESP1， EFLAGS1， 用戶(hù)空間的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è)置用戶(hù)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)核為:
  | 用戶(hù)堆棧的SS1 | 0xbfffe7ec | EFLAGS1 | 用戶(hù)空間的CS1 | 0x80482e8 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1
 
  最后，進(jìn)行RESTORE_ALL，內(nèi)核棧上的內(nèi)容為：
  | 用戶(hù)堆棧的SS1 | 0xbfffe7ec | EFLAGS1 | 用戶(hù)空間的CS1 | 0x80482e8
 
  RESTORE_ALL里執(zhí)行完iret后，寄存器內(nèi)容為： EIP為0x80482e8(即sig_int),esp為0xbfffe7ec 。 于是用戶(hù)空間到了步驟 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ū)分）
  | 用戶(hù)堆棧的SS2 | 用戶(hù)堆棧的ESP2 | EFLAGS2 | 用戶(hù)空間的CS2 | EIP2 | ? | ES2 | DS2 | EAX2 | EBP2 | EDI2 | ESI2 | EDX2 | ECX2 | EBX2
  sig_return要做的主要工作就是根據(jù)用戶(hù)棧里sigframe的值修改內(nèi)核棧里的內(nèi)容，使內(nèi)核棧變?yōu)?
  | 用戶(hù)堆棧的SS1 | 用戶(hù)堆棧的ESP1 | EFLAGS1 | 用戶(hù)空間的CS1 | EIP1 | ? | ES1 | DS1 | EAX1 | EBP1 | EDI1 | ESI1 | EDX1 | ECX1 | EBX1
                                                  
  至此內(nèi)核棧里的內(nèi)容和進(jìn)行信號(hào)處理前一樣了。經(jīng)過(guò)RESTORE_ALL后，用戶(hù)堆棧里的內(nèi)容也和以前一樣（主要指ESP的值一樣）。

  "kill -INT 4639" 只是一段小插曲。程序從原處開(kāi)始運(yùn)行。