ARM Linux异常处理之data abort（一）

本文简要分析了ARM Linux的data abort异常处理过程，内核版本2.6.28，s3c6410平台。

异常向量与程序跳转

data abort是ARM体系定义的异常之一。异常发生时，ARM会自动跳转到异常向量表中，通过向量表中的跳转命令跳转到相应的异常处理中去。

ARM的异常处理向量表在entry-armv.S文件中：

       .globl      __vectors_start

__vectors_start:

       swi   SYS_ERROR0

       b     vector_und + stubs_offset

       ldr   pc, .LCvswi + stubs_offset

       b     vector_pabt + stubs_offset

       b     vector_dabt + stubs_offset

       b     vector_addrexcptn + stubs_offset

       b     vector_irq + stubs_offset

       b     vector_fiq + stubs_offset

对于data abort，对应的跳转地址是vector_dabt + stubs_offset。这个地址的指令定义也在entry-armv.S：

       vector_stub     dabt, ABT_MODE, 8

       .long       __dabt_usr                       @  0  (USR_26 / USR_32)

       .long       __dabt_invalid                     @  1  (FIQ_26 / FIQ_32)

       .long       __dabt_invalid                     @  2  (IRQ_26 / IRQ_32)

       .long       __dabt_svc                       @  3  (SVC_26 / SVC_32)

       .long       __dabt_invalid                     @  4

       .long       __dabt_invalid                     @  5

       .long       __dabt_invalid                     @  6

       .long       __dabt_invalid                     @  7

       .long       __dabt_invalid                     @  8

       .long       __dabt_invalid                     @  9

       .long       __dabt_invalid                     @  a

       .long       __dabt_invalid                     @  b

       .long       __dabt_invalid                     @  c

       .long       __dabt_invalid                     @  d

       .long       __dabt_invalid                     @  e

       .long       __dabt_invalid                     @  f

vector_stub是一个宏定义：

       .macro     vector_stub, name, mode, correction=0

       .align      5

vector_/name:

       .if /correction

       sub  lr, lr, #/correction

       .endif

 

       @

       @ Save r0, lr_ (parent PC) and spsr_

       @ (parent CPSR)

       @

       stmia       sp, {r0, lr}             @ save r0, lr

       mrs  lr, spsr                          @ 保存跳转之前的CPSR到lr寄存器

       str    lr, [sp, #8]                    @ save spsr

 

       @

       @ Prepare for SVC32 mode.  IRQs remain disabled.

       @

       mrs  r0, cpsr

       eor   r0, r0, #(/mode ^ SVC_MODE)

       msr  spsr_cxsf, r0                 @ 准备进入svc模式

 

       @

       @ the branch table must immediately follow this code

       @

       and  lr, lr, #0x0f                    @ 得到跳转前所处的模式（usr、svr等）

       mov r0, sp

       ldr   lr, [pc, lr, lsl #2]            @ 根据模式跳转到相应的data abort指令，并进入svc模式

       movs       pc, lr                     @ branch to handler in SVC mode

ENDPROC(vector_/name)

       .endm

由代码中红色标注部分可看出，对于同一个异常，根据进入异常之前所处的模式，会跳转到不同的指令分支，这些指令分支紧跟在vector_stub宏定义的后面。如果进入data abort之前处于usr模式，那么跳转到__dabt_usr；如果处于svc模式，那么跳转到__dabt_svc；否则跳转到__dabt_invalid。

实际上，进入异常向量前Linux只能处于usr或者svc两种模式之一。这时因为irq等异常在跳转表中都要经过vector_stub宏，而不管之前是哪种状态，这个宏都会将CPU状态改为svc模式。

usr模式即Linux中的用户态模式，svc即内核模式。

下面看一下在不同模式下进入data abort时的处理过程。

svc模式进入data abort

svc模式进入data abort，也就是Linux的内核模式进入data aboart时，会跳转到__dabt_svc。

__dabt_svc:

       svc_entry               @ 保护寄存器现场

 

       mrs  r9, cpsr

       tst    r3, #PSR_I_BIT            @ 检查是否要开中断

       biceq       r9, r9, #PSR_I_BIT

       bl    CPU_DABORT_HANDLER  @ 处理异常之前的准备工作

 

       msr  cpsr_c, r9

       mov r2, sp

       bl    do_DataAbort        @ 主要操作都在这里，本文暂不研究

 

       disable_irq

 

       ldr   r0, [sp, #S_PSR]

       msr  spsr_cxsf, r0

       ldmia      sp, {r0 - pc}^                @ load r0 - pc, cpsr

ENDPROC(__dabt_svc)

CPU_DABORT_HANDLER的定义在glue.h：

#define CPU_DABORT_HANDLER v6_early_abort

对于s3c6410，v6_early_abort的定义在abort-ev6.S中，里面涉及到很多ARM的细节操作，但对我们来说，只需要了解下面这两句即可：

       mrc  p15, 0, r1, c5, c0, 0              @ get FSR

       mrc  p15, 0, r0, c6, c0, 0              @ get FAR

这两句用于读取协处理器CP15的C5、C6寄存器。当data abort异常发生时，C5寄存器中保存的值指明了是哪种原因导致的异常，具体原因可在介绍arm的资料中找到。C6寄存器中保存的是导致data abort的存储地址。

usr模式进入data abort

usr模式进入data abort，也就是Linux的用户模式进入data bort时，会跳转到__dabt_usr。

__dabt_usr:

       usr_entry                                    @ 保护寄存器现场

       kuser_cmpxchg_check

 

       bl    CPU_DABORT_HANDLER  @ 与svc模式时处理过程一样

 

       enable_irq                                  @ 开中断

       mov r2, sp

       adr  lr, ret_from_exception            @ 重设返回地址

       b     do_DataAbort                      @ 与svc模式时处理过程一样

ENDPROC(__dabt_usr)

由代码可知，用户模式和内核模式的data abort处理过程类似，区别在于：

l         用户模式下data abort处理一定是开中断的；内核模式下则由具体情况决定。

l         用户模式下异常处理返回地址被设为ret_from_exception (entry-armv.S文件)；内核模式下则返回到出现异常的那条语句。

下面看一下ret_from_exception：

ENTRY(ret_from_exception)

       get_thread_info tsk

       mov why, #0

       b     ret_to_user

ENDPROC(__pabt_usr)

ret_to_user会判断是否需要进行进程调度，并最终返回到用户空间。用户空间data abort时可能产生进程调度的原因就在这里。

未定义状态的data abort

除了usr和svc模式之外，其它模式下发生data abort时，都会调用__dabt_invalid函数。这里所说的其它模式在linux正常运行过程中是不应该存在的，所以如果进入__dabt_invalid函数，那就代表Linux内核应该崩溃了。

__dabt_invalid:

       inv_entry BAD_DATA

       b     common_invalid

ENDPROC(__dabt_invalid)

inv_entry宏做的主要工作是保存寄存器现场（压栈）。

common_invalid做一些必要的设置，最终调用C函数bad_mode (traps.c)。

asmlinkage void bad_mode(struct pt_regs *regs, int reason)

{

       console_verbose();

 

       printk(KERN_CRIT "Bad mode in %s handler detected/n", handler[reason]);

 

       die("Oops - bad mode", regs, 0);

       local_irq_disable();

       panic("bad mode");

}

由代码可知，bad_mode主要是输出一些必要的信息，然后调用panic函数，进入死循环。