Crash 变量解析

Crash工具用于解析Vmcore文件，Vmcore文件为通过kdump等手段收集的操作系统core dump信息，在不采用压缩的情况下，其相当于整个物理内存的镜像，所以其中包括了最全面、最完整的信息，对于分析定位各种疑难问题有极大的帮助。配置kdump后，在内核panic后，会自动进入kump流程，搜集Vmcore。
Crash工具即为专门用于分析vmcore文件的工具，其中提供了大量的实用分析命令，极大的提高了vmcore的分析效率。
在分析vmcore的过程中，常常需要解析内核某个流程中的关键变量的值，以便确认故障当时系统的状态，本文主要介绍变量的解析方法，主要分全局变量和局部变量两种情况。
1、全局变量解析非常简单，可通过在crash中直接p <变量名>打印，如：

1.crash> p jiffies
2.jiffies = $3 = 5540265294

2、局部变量的解析比较复杂。
Vmcore搜集的仅为故障当时内存使用情况的一个快照，是静态信息，无法进行动态调试(虽然听说可以，但没见过~~)，对于某个进程而言，在Vmcore中能发掘的进程上下文信息，通常只有堆栈和寄存器的值。而我们了解，通常局部变量在栈中分配，但也可能直接使用寄存器保存，所以可以(也只能)通过“寻找局部变量跟堆栈或寄存器的关系”来解析局部变量的值。所以这里分两种情况：
1）位于栈中的局部变量
这种情况比较常见，此时，局部变量必然位于某一级函数的堆栈中，该局部变量可能通过指针一级级向底层函数传递，所以可能位于多个函数的堆栈中，可以从不同的函数堆栈中解析。但解析会比较困难，难点在于难以确认相关变量在堆栈中的具体位置，解析方法很灵活，需要结合相关源代码，仔细分析流程，找到关键的点，更多的取决于分析者的经验和代码理解能力。
如下以实例说明解析过程：
vmcore中某阻塞的进程有如下的堆栈：

1.crash> bt 9242
2.PID: 9242 TASK: ffff8805f3a21540 CPU: 4 COMMAND: "xxx"
3. #0 [ffff8805f3a23428] schedule at ffffffff814f8b42
4. #1 [ffff8805f3a234f0] schedule_timeout at ffffffff814f9a6d
5. #2 [ffff8805f3a235a0] __down at ffffffff814fa992
6. #3 [ffff8805f3a235f0] down at ffffffff81097c11
7. #4 [ffff8805f3a23620] xfs_buf_lock at ffffffffa0523433 [xfs]
8. #5 [ffff8805f3a23650] _xfs_buf_find at ffffffffa05235f2 [xfs]
9. #6 [ffff8805f3a236c0] xfs_buf_get at ffffffffa05237db [xfs]
10. #7 [ffff8805f3a23700] xfs_buf_read at ffffffffa0523e4c [xfs]
11. #8 [ffff8805f3a23730] xfs_trans_read_buf at ffffffffa0519a98 [xfs]
12. #9 [ffff8805f3a23780] xfs_read_agf at ffffffffa04cfd26 [xfs]
13.#10 [ffff8805f3a237c0] xfs_alloc_read_agf at ffffffffa04cfe99 [xfs]
14.#11 [ffff8805f3a237f0] xfs_alloc_fix_freelist at ffffffffa04d28a1 [xfs]
15.#12 [ffff8805f3a238d0] xfs_alloc_vextent at ffffffffa04d2e16 [xfs]

可以看出，进程阻塞在信号量上，需要解析如下函数中xfs_buf_t *bp变量的值，以确认其中bp->b_sema信号量的状态。

1.void
2.xfs_buf_lock(
3.    xfs_buf_t        *bp)
4.{
5.    trace_xfs_buf_lock(bp, _RET_IP_);
6.
7.    if (atomic_read(&bp->b_io_remaining))
8.        blk_run_address_space(bp->b_target->bt_mapping);
9.    down(&bp->b_sema);
10.    XB_SET_OWNER(bp);
11.
12.    trace_xfs_buf_lock_done(bp, _RET_IP_);
13.}

该变量是通过入参从上级函数传入的，而跟踪上级函数会发现其为在上级函数_xfs_buf_find中分配
bp变量是在上级函数_xfs_buf_find定义局部变量，那么其通常会在该级栈中分配空间。但难点还在于如何确认该变量在堆栈中的位置，关键在于找到“寄存器和堆栈关联”的地方，还得分析关键代码流程：

1._xfs_buf_find(
2.    xfs_buftarg_t        *btp,    /* block device target        */
3.    xfs_off_t        ioff,    /* starting offset of range    */
4.    size_t            isize,    /* length of range        */
5.    xfs_buf_flags_t        flags,
6.    xfs_buf_t        *new_bp)
7.{
8.    xfs_off_t        range_base;
9.    size_t            range_length;
10.    xfs_bufhash_t        *hash;
11.    xfs_buf_t        *bp, *n;
12.
13.    range_base = (ioff << BBSHIFT);
14.    range_length = (isize << BBSHIFT);
15....
16.found:
17.    spin_unlock(&hash->bh_lock);
18.
19.    /* Attempt to get the semaphore without sleeping,
20.     * if this does not work then we need to drop the
21.     * spinlock and do a hard attempt on the semaphore.
22.     */
23.    if (down_trylock(&bp->b_sema)) {
24.        if (!(flags & XBF_TRYLOCK)) {
25.            /* wait for buffer ownership */
26.            xfs_buf_lock(bp);
27.            XFS_STATS_INC(xb_get_locked_waited);

可以看到，bp是作为xfs_buf_lock函数的入参传入的，那这里应该会通过寄存器或其它方式进行传参，则必然会对bp所在的堆栈位置进行操作，由此应能找到bp在堆栈中的位置。
反汇编相关代码：

1.crash> dis -l _xfs_buf_find
2./usr/src/debug/kernel-2.6.32-220.el6/linux-2.6.32-220.el6.x86_64/fs/xfs/linux-2.6/xfs_buf.c: 431
3.0xffffffffa05234f0 <_xfs_buf_find>: push %rbp
4.0xffffffffa05234f1 <_xfs_buf_find+1>: mov %rsp,%rbp
5.0xffffffffa05234f4 <_xfs_buf_find+4>: push %r15
6.0xffffffffa05234f6 <_xfs_buf_find+6>: push %r14
7....
8.0xffffffffa05235e6 <_xfs_buf_find+246>: mov %rcx,%rdi
9.0xffffffffa05235e9 <_xfs_buf_find+249>: mov %rcx,-0x58(%rbp) //可以看出rbp偏移0x58即为入参bp的值
10.0xffffffffa05235ed <_xfs_buf_find+253>: callq 0xffffffffa05233e0 <xfs_buf_lock> //此处调用xfs_buf_lock
11....

找到调用xfs_buf_lock函数的地方，在此之前准备入参，操作了堆栈-0x58(%rbp) ，可以看出rbp偏移0x58即为入参bp的值
再看看堆栈中-0x58(%rbp)中的内容具体是啥：

1.crash> bt -f 9242
2.PID: 9242 TASK: ffff8805f3a21540 CPU: 4 COMMAND: "xxx"
3. #0 [ffff8805f3a23428] schedule at ffffffff814f8b42
4.    ffff8805f3a23430: 0000000000000082 ffff8805f3a234a8
5.    ffff8805f3a23440: 0000000181164d0e ffff880c20518300
6.    ffff8805f3a23450: 00051200f3a21b00 ffff880c20518300
7.    ffff8805f3a23460: 00051200f3a21540 ffff8805f3a21af8
8.    ffff8805f3a23470: ffff8805f3a23fd8 000000000000f4e8
9.    ffff8805f3a23480: ffff8805f3a21af8 ffff880c20e1a080
10.    ffff8805f3a23490: ffff8805f3a21540 ffff8805f3a234d8
11.    ffff8805f3a234a0: 0000000000000246 ffff880c1d102400
12.    ffff8805f3a234b0: 0000000000000246 ffff8805f3a234d8
13.    ffff8805f3a234c0: ffff8802ecd784b8 7fffffffffffffff
14.    ffff8805f3a234d0: ffff8805f3a235a8 7fffffffffffffff
15.    ffff8805f3a234e0: 0000000000000200 ffff8805f3a23598
16.    ffff8805f3a234f0: ffffffff814f9a6d
17....
 #5 [ffff8805f3a23650] _xfs_buf_find at ffffffffa05235f2 [xfs]
    ffff8805f3a23658: ffff8805f563e600 ffff8802ecd78480
    ffff8805f3a23668: 0001400500000000 ffff8805f563e690
    ffff8805f3a23678: ffff8805f3a236b8 0000000000000001
    ffff8805f3a23688: ffff8805f3a21af8 ffff8808fe07c0c0
    ffff8805f3a23698: 0000000000014005 000000003a382231
    ffff8805f3a236a8: 0000000000000001 ffff8805f563e0c0
rsp--> ffff8805f3a236b8: ffff8805f3a236f8 ffffffffa05237db

我们知道：
（1）栈的地址是向低地址延伸的，也就是说压栈时，sp(栈顶地址)减小。
（2）第一个压栈的上级函数的返回地址，所以其中的ffffffffa05237db为上级函数的返回地址（从上述堆栈中可以明显看出~）
在_xfs_buf_find()函数反汇编的第一句，就对rbp(即上级堆栈栈帧指针)进行了压栈，所以 ffff8805f3a236f8为rbp。
0xffffffffa05234f0 <_xfs_buf_find>: push %rbp
此时的rsp应该就是ffff8805f3a236b8：接下来：
0xffffffffa05234f1 <_xfs_buf_find+1>: mov %rsp,%rbp
那么此时的rbp也就等于ffff8805f3a236b8，那么rbp-0x58就是ffff8802ecd78480即为我们苦苦寻找的bp指针了！！