詳解Linux核心例外狀況處理體繫結構

標籤：

本節內容：Linux核心例外狀況處理的的初始化過程和異常發生時的處理流程。

【首先來區分一下兩個概念：中斷(Interrupt)和異常(Exception)。中斷屬於異常的一種，就拿2440開發板來說，他有60多種中斷源，例如來自DMA控制器、UART、IIC和外部中斷等。2440有一個專門的中斷控制器來處理這些中斷，中斷控制器在接收到這些中斷訊號之後就需要ARM920T進入IRQ或FIQ模式進行處理，這兩種模式也是中斷異常的僅有模式。而異常的概念要廣的多，它包括複位、未定義指令、非強制中斷、IRQ等等。還有一點知識就是，中斷這種異常在響應之前到來之前是需要程式員進行什麼優先順序、是否要屏蔽訊號之類的初始化的，而其他比如未定義指令是不用的，只要發生了就跳到異常向量入口取址執行。因此下面初始化內容中的第（2）點是針對中斷這種異常的設定的】

一、初始化設定：

（1）異常向量相關的設定：start_kernel()-->setup_arch()-->early_trap_init()函數來擔任這個任務。在arch/arm/kernel/traps.c檔案件中定義：這個函數很有分量，值得細細分析！！！

<span style="font-size:14px;">void __init early_trap_init(void){unsigned long vectors = CONFIG_VECTORS_BASE;extern char __stubs_start[], __stubs_end[];extern char __vectors_start[], __vectors_end[];extern char __kuser_helper_start[], __kuser_helper_end[];int kuser_sz = __kuser_helper_end - __kuser_helper_start;/* * 看下面這段英文注釋，代碼就一目瞭然了，就是把異常向量表、和異常處理那部分代碼複製到指定的地址處 * Copy the vectors, stubs and kuser helpers (in entry-armv.S) * into the vector page, mapped at 0xffff0000, and ensure these * are visible to the instruction stream. */memcpy((void *)vectors, __vectors_start, __vectors_end - __vectors_start); memcpy((void *)vectors + 0x200, __stubs_start, __stubs_end - __stubs_start); memcpy((void *)vectors + 0x1000 - kuser_sz, __kuser_helper_start, kuser_sz); /* * Copy signal return handlers into the vector page, and * set sigreturn to be a pointer to these. */memcpy((void *)KERN_SIGRETURN_CODE, sigreturn_codes,       sizeof(sigreturn_codes));flush_icache_range(vectors, vectors + PAGE_SIZE);modify_domain(DOMAIN_USER, DOMAIN_CLIENT);}</span>

詳細函數分析：
將異常向量表複製到vectors地址處，vectors在函數的第一句就被賦值為“CONFIG_VECTORS_BASE”，經驗告訴我們它是個核心編譯配置項，去核心的頂層目錄裡邊的“.config”檔案搜尋就出來，果然就有“CONFIG_VECTORS_BASE=0xffff0000”這麼一句話。
好，同樣問題就來了，我們之前瞭解過的中斷向量是放到0x00000000地址開始處，把中斷向量放到0xffff0000 異常觸發時cpu還能自動找到？答案是能！
在ARM920T的使用手冊裡邊有涉及相關的內容：協處理控制寄存器CP15的C1寄存器的第[13]位就是用來設定異常向量的存放位置的，該位為0存放到0x0000000開始處，為1存放到0xffff0000開始處。

到這裡Linux核心例外狀況向量設定的工作就算是完成了。可是想想：設定完這些異常向量之後，異常發生了，CPU是怎麼一個處理過程？？？接著往下分析：Linux核心處理異常主要流程。

繼續分析就得從異常向量表來開始入手，__vectors_start和__vectors_end在arch/arm/kernel/entry-armv.S檔案中有定義。他們就是核心例外狀況向量表的起始和結束位址。

<span style="font-size:14px;">.........globl__vectors_start__vectors_start:swiSYS_ERROR0    ;arm在複位異常發生時來這裡執行bvector_und + stubs_offsetldrpc, .LCvswi + stubs_offsetbvector_pabt + stubs_offsetbvector_dabt + stubs_offsetbvector_addrexcptn + stubs_offsetbvector_irq + stubs_offsetbvector_fiq + stubs_offset.globl__vectors_end........</span>

下面以第一個調轉指令“ bvector_und + stubs_offset”的分析為例，發現怎麼在源碼裡面都找不到vector_und這個東東，各種查資料之後發現特麼是個彙編宏定義，幹！展開來解解氣，建議先熟悉一下彙編宏定義規則。

.macro    MACRO_NAME   PARA1   PARA2   ......

......內容......

.endm

同樣在這個檔案中找到了vector_stub這個宏：

<span style="font-size:14px;">.macrovector_stub, name, mode, correction=0.align5  @將異常入口強制進行2^5位元組對齊，即一個cache line大小對齊，出於效能考慮vector_\name:.if \correction @correction=0 所以分支無效sublr, lr, #\correction.endif.endif...........movspc, lr@ branch to handler in SVC modeENDPROC(vector_\name).endm</span>

以宏“vector_stub  und,   UND_MODE”為例將其展開為：

<span style="font-size:14px;">vector_und:   @@ 此時已進入UND_MOD，lr=上一個模式被打斷時的PC值，下面三條指令是保護上個模式的現場@stmiasp, {r0, lr}<span style="white-space:pre"></span>@ save r0, lrmrslr, spsr               <span style="white-space:pre"></span>@ 準備儲存上個模式的cpsr值，因為他被放到了UND_MODE的spsr中strlr, [sp, #8]@ save spsr to stack@@ Prepare for SVC32 mode.  IRQs remain disabled. 注意前面的“Prepare”，這裡還不是真正切換到SVC，只是準備！！不要緊張@mrsr0, cpsr             @ r0=0x1b  (UND_MODE)eorr0, r0, #(\mode ^ SVC_MODE)<span style="white-space:pre"></span>@ 邏輯異或指令msrspsr_cxsf, r0   @ cxsf是spsr寄存器的控制域（C）、擴充域（X）、狀態域（S）、標誌域（F），注意這裡的spsr是UND管理員模式的@@ the branch table must immediately follow this code 下一級跳轉表必須要緊跟在這一段代碼之後（這一點很重要）@andlr, lr, #0x0f@ 執行這條指令之前：lr = 上個模式的cpsr值，現在取出其低四位--模式控制位的[4:0],關鍵點又來了：查看2440晶片手冊可以知道，這低4位二進位值為十進位數值的 0-->User_Mode; 1-->Fiq_Mode; 2-->Irq_Mode; 3-->SVC_Mode; 7-->Abort_Mode; 11-->UND_Mode，明白了這些下面的處理就會恍然大悟，原來找到那些異常處理分支是依賴這4位的值來實現的movr0, sp@ 將SP值儲存到R0是為了之後切換到SVC模式時將這個模式下堆棧中的資訊轉而儲存到SVC模式下的堆棧中ldrlr, [pc, lr, lsl #2] @ 我第一次遇到LDR的這種用法，找了一下LDR的資料發現是這個意思：將pc+lr*4的計算結果重新儲存到lr中，我們知道pc是指向當前指令的下兩條指令處的地址的，也就是指向了“.long__und_usr”movspc, lr@ branch to handler in SVC mode 前方高能！關鍵的地方來了！在跳轉到第二級分支的同時CPU的工作模式從UND_MODE強制切換到SVC_MODE,這是由於MOVS指令在賦值的同時會將spsr的值賦給cpsrENDPROC(vector_und).long__und_usr@  0 (USR_26 / USR_32)運行使用者模式下觸發未定義指令異常.long__und_invalid@  1 (FIQ_26 / FIQ_32).long__und_invalid@  2 (IRQ_26 / IRQ_32).long__und_svc@  3 (SVC_26 / SVC_32)運行使用者模式下觸發未定義指令異常.long__und_invalid@  4 其他模式下面不能發生未定義指令異常，否則都使用__und_invalid分支處理這種異常.long__und_invalid@  5.long__und_invalid@  6.long__und_invalid@  7.long__und_invalid@  8.long__und_invalid@  9.long__und_invalid@  a.long__und_invalid@  b.long__und_invalid@  c.long__und_invalid@  d.long__und_invalid@  e.long__und_invalid@  f</span>

【附加註釋：在arch\arm\include\asm\ptrace.h中有:#define  SVC_MODE  0x00000013 和 #define UND_MODE  0x0000001b

這樣做的目的是什嗎？有什麼天大的好處？肯定有！因為，現在的我還沒敢懷疑核心會做一些沒用的事情
Linux的中斷管理的設計思路都是這樣的：例外狀況事件觸發，cpu自動跳到異常向量表處執行，同時也切換到對應的模式，有種變色龍的感覺，但是隨後立即有段代碼強制讓cpu切換到SVC管理員模式進行異常處理，當然有一點值得一說，reset異常是進入使用者模式的，此時的異常向量存放的是swi指令，swi指令是進入svc管理員模式的(也叫核心模式)結果可想而知，也得聽話，乖乖進入管理員模式。如此一來，核心管理異常就方便多了，從宏觀的角度來看，cpu絕大部分時間是停留在user和svc模式的，要不就是user模式下正常工作，要不就是svc模式下異常處理，那段切換的時間完全被忽略，有種英雄就被人們忘記的感覺。也就是說可以看做核心要不就是在user模式下要不就是在svc模式下被其他各種異常中斷打斷咯。如果這些都意會到了，下面的內容分析，肯定妥妥的，就是這麼自信】

================================================================================================================
執行到“movs pc, lr”這一句，找到了branch table中的一項，現在我們繼續往下分析，假設進入UND_MODE之前是User模式，那麼接下來會到__und_usr分支去繼續執行
__und_usr標號也是在該檔案中定義，代碼如下：

<span style="font-size:14px;">__und_usr:usr_entry   @搜一下發現這是一個宏定義，先猜測一下功能是：將usr模式下的寄存器、中斷返回地址儲存到堆棧中。可以說是接管UND_MODE下儲存的資訊和未儲存資訊@@ fall through to the emulation code, which returns using r9 if@ it has emulated the instruction, or the more conventional lr@ if we are to treat this as a real undefined instruction@@  r0 - instruction@adrr9, ret_from_exceptionadrlr, __und_usr_unknowntstr3, #PSR_T_BIT@ Thumb mode?subeqr4, r2, #4@ ARM instr at LR - 4subner4, r2, #2@ Thumb instr at LR - 21:ldreqtr0, [r4]beqcall_fpe@ Thumb instruction#if __LINUX_ARM_ARCH__ >= 72:ldrhtr5, [r4], #2andr0, r5, #0xf800@ mask bits 111x x... .... ....cmpr0, #0xe800@ 32bit instruction if xx != 0blo__und_usr_unknown  @blo小於跳轉指令。找到真正異常處理函數入口3:ldrhtr0, [r4]addr2, r2, #2@ r2 is PC + 2, make it PC + 4orrr0, r0, r5, lsl #16#elseb__und_usr_unknown #endif UNWIND(.fnend)ENDPROC(__und_usr)</span>

=================================================================================================================
usr_entry宏內容：

<span style="font-size:14px;">.macrousr_entry UNWIND(.fnstart) UNWIND(.cantunwind)subsp, sp, #S_FRAME_SIZE   @ 通過尋找和計算S_FRAME_SIZE=4*18=72stmibsp, {r1 - r12}  <span style="white-space:pre"></span>@ 從開始的Usr_MODE到UND_MODE，再到現在的SVC_MODE，程式中都沒有去操作通用寄存器中的R1-R12，因此可以直接將他們入棧。接下來就可以隨便使用這些寄存器了。ldmiar0, {r1 - r3}  <span style="white-space:pre"></span>@ 之前已將UND_MODE下棧頂指標儲存到R0，出棧後r1=Usr_r0,r2=Usr_lr,r3=Usr_cpsraddr0, sp, #S_PC@ here for interlock avoidance  從這往下一小部分代碼尚未消化movr4, #-1strr1, [sp]<span style="white-space:pre"></span>@ save the "real" r0 copied@ from the exception stack@@ We are now ready to fill in the remaining blanks on the stack:@@  r2 - lr_<exception>, already fixed up for correct return/restart@  r3 - spsr_<exception>@  r4 - orig_r0 (see pt_regs definition in ptrace.h)@@ Also, separately save sp_usr and lr_usr@stmiar0, {r2 - r4}stmdbr0, {sp, lr}^@@ Enable the alignment trap while in kernel mode@alignment_trap r0@@ Clear FP to mark the first stack frame@zero_fp.endm</span>

=========================================================================================================
__und_usr_unknown也是在這個檔案中定義：

<span style="font-size:14px;">__und_usr_unknown:enable_irqmovr0, spadrlr, ret_from_exception  @ 這裡就是異常中斷的返回，先將返回前處理的處理函數的地址給lr寄存器，下面調用完C函數之後直接就可以返回bdo_undefinstr   @ 最終調用C函數進行複雜的處理 在arch/arm/kernel/traps.c中ENDPROC(__und_usr_unknown)</span>

小結一下Linux異常處理流程：

異常發生前工作狀態，到異常發生，去異常向量表找到入口地址，（這算異常發生之後跳轉到第一個處理分支），進入異常模式，保護部分現場，強制進入SVC管理員模式，根據異常發生前的工作模式找到異常處理的第二級分支，在該模式下面接過異常模式堆棧中的資訊，接著儲存異常發生時異常模式還未儲存的資訊，準備好處理完畢返回處理常式的地址，調用異常處理函數。

（2）中斷相關初始化：init_IRQ()函數來完成，他直接由srart_kernel()函數來調用。定義於arch/arm/kernel/irq.c。【這一點內容在下一篇博文中發表】

詳解Linux核心例外狀況處理體繫結構