kgdb bt 跟 dump_stack() 差异

shihyu

为什么使用 kgdb 的 bt 跟代码中使用 dump_stack() 打印出来讯息差异那多？

第一组讯息是 gdb bt 打印出来就很完整 , 而  第二组是 dump_stack() 打印出来讯息就少很多

这是什么原因造成？

1. #0  lowmem_shrink (s=<optimized out>, sc=0xec923c84) at drivers/staging/android/lowmemorykiller.c:89
   
2. #1  0xc00a0374 in do_shrinker_shrink (nr_to_scan=0, sc=0xec923d78, shrinker=0xc0518488 <lowmem_shrinker>) at mm/vmscan.c:277
   
3. #2  shrink_slab (shrink=0xec923d78, shrink@entry=0xec923d70, nr_pages_scanned=1, lru_pages=3226603292, lru_pages@entry=52207) at mm/vmscan.c:326
   
4. #3  0xc00a3010 in do_try_to_free_pages (shrink=0xec923d70, sc=0xec923d78, zonelist=0xc0520830 <contig_page_data+2208>) at mm/vmscan.c:2426
   
5. #4  try_to_free_pages (zonelist=zonelist@entry=0xc0520830 <contig_page_data+2208>, order=order@entry=64, gfp_mask=gfp_mask@entry=131290, nodemask=nodemask@entry=0x0)
   
6.     at mm/vmscan.c:2509
   
7. #5  0xc0097c24 in __alloc_pages_direct_reclaim (did_some_progress=<synthetic pointer>, migratetype=131290, preferred_zone=0x40, alloc_flags=2, nodemask=0x0,
   
8.     high_zoneidx=<optimized out>, zonelist=0xc0520830 <contig_page_data+2208>, order=0, gfp_mask=131290) at mm/page_alloc.c:2129
   
9. #6  __alloc_pages_slowpath (migratetype=131290, preferred_zone=0x1, nodemask=0x0, high_zoneidx=ZONE_MOVABLE, zonelist=0xc0520830 <contig_page_data+2208>, order=0, gfp_mask=131290)
   
10.     at mm/page_alloc.c:2351
    
11. #7  __alloc_pages_nodemask (gfp_mask=131290, order=order@entry=0, zonelist=0xc0520830 <contig_page_data+2208>, nodemask=nodemask@entry=0x0) at mm/page_alloc.c:2479
    
12. #8  0xc00b11a8 in __alloc_pages (zonelist=<optimized out>, order=0, gfp_mask=131290) at include/linux/gfp.h:302
    
13. #9  alloc_pages_node (order=0, gfp_mask=131290, nid=<optimized out>) at include/linux/gfp.h:312
    
14. #10 __alloc_zeroed_user_highpage (vaddr=793632768, vma=0xecefd230, movableflags=8) at include/linux/highmem.h:192
    
15. #11 alloc_zeroed_user_highpage_movable (vaddr=793632768, vma=0xecefd230) at include/linux/highmem.h:214
    
16. #12 do_anonymous_page (flags=3221952572, pmd=0xecefd230, page_table=0xec1fc378, address=793632768, vma=0xecefd230, mm=0xec905c80) at mm/memory.c:3179
    
17. #13 handle_pte_fault (mm=mm@entry=0xec905c80, vma=vma@entry=0xecefd230, address=address@entry=793632768, pte=0xec1fc378, pmd=pmd@entry=0xec92cbd0, flags=flags@entry=41)
    
18.     at mm/memory.c:3484
    
19. #14 0xc00b183c in handle_mm_fault (mm=mm@entry=0xec905c80, vma=vma@entry=0xecefd230, address=address@entry=793632768, flags=flags@entry=41) at mm/memory.c:3598
    
20. #15 0xc0013c0c in __do_page_fault (tsk=0xec91c400, flags=41, fsr=2071, addr=793632768, mm=0xec905c80) at arch/arm/mm/fault.c:247
    
21. #16 do_page_fault (addr=793632768, fsr=2071, regs=0xec923fb0) at arch/arm/mm/fault.c:309
    
22. #17 0xc00083b0 in do_DataAbort (addr=793632768, fsr=2071, regs=0xec923fb0) at arch/arm/mm/fault.c:548
    
23. ---Type <return> to continue, or q <return> to quit---
    
24. #18 0xc000dc74 in __dabt_usr () at arch/arm/kernel/entry-armv.S:410

复制代码

1. <4>[<c0012a14>] (unwind_backtrace+0x0/0xf0) from [<c0011514>] (dump_stack+0x10/0x14)
   
2. <4>[<c0011514>] (dump_stack+0x10/0x14) from [<c02a3f4c>] (lowmem_shrink+0x9c/0x554)
   
3. <4>[<c02a3f4c>] (lowmem_shrink+0x9c/0x554) from [<c00a0374>] (shrink_slab+0xbc/0x394)
   
4. <4>[<c00a0374>] (shrink_slab+0xbc/0x394) from [<c00a3010>] (try_to_free_pages+0x2d8/0x510)
   
5. <4>[<c00a3010>] (try_to_free_pages+0x2d8/0x510) from [<c0097c24>] (__alloc_pages_nodemask+0x424/0x7a0)
   
6. <4>[<c0097c24>] (__alloc_pages_nodemask+0x424/0x7a0) from [<c00b11a8>] (handle_pte_fault+0x14c/0x72c)
   
7. <4>[<c00b11a8>] (handle_pte_fault+0x14c/0x72c) from [<c00b183c>] (handle_mm_fault+0xb4/0xc8)
   
8. <4>[<c00b183c>] (handle_mm_fault+0xb4/0xc8) from [<c0013c0c>] (do_page_fault+0x110/0x280)
   
9. <4>[<c0013c0c>] (do_page_fault+0x110/0x280) from [<c00083b0>] (do_DataAbort+0x38/0x98)
   
10. <4>[<c00083b0>] (do_DataAbort+0x38/0x98) from [<c000dc74>] (__dabt_usr+0x34/0x40)
    
11. <4>Exception stack(0xccebffb0 to 0xccebfff8)
    
12. <4>ffa0:                                     985c0000 01010101 00042fc0 01010101
    
13. <4>ffc0: 01010101 01010101 01010101 01010101 00000000 00000000 00000000 be8fcafc
    
14. <4>ffe0: 01010101 be8fcaa8 01010101 b6f277a8 20000010 ffffffff
    

复制代码

shihyu

有谁知道为什么？

nswcfd

是同一个内核么？编译选项啥的都一样？

shihyu

内核&编译选项都一样

nswcfd

这个kgdb可以打印出行号信息, 是通过串口打印出来的远程设备的栈？

nswcfd

在本机使用kdb（不是kgdb）的bt命令打印的stack trace是什么样子？
看代码跟dump_stack一样，都是调用了show_stack，估计是类似的？

kgdb是在kernel端实现了一个gdb stub，具体的bt是由对端的gdb完成的，
gdb有debug信息，但还是不明白为什么能够把栈展开的更详细一些（毕竟stack上的内容都是一样的）？

nswcfd

以下高亮部分是有区别的地方，可以发现，这些地方都没有栈的指针。
这些信息应该是gdb自己添加进去的。

#0  lowmem_shrink (s=<optimized out>, sc=0xec923c84) at drivers/staging/android/lowmemorykiller.c:89 */
#1 0xc00a0374 in do_shrinker_shrink (nr_to_scan=0, sc=0xec923d78, shrinker=0xc0518488 <lowmem_shrinker> at mm/vmscan.c:277
#2  shrink_slab (shrink=0xec923d78, shrink@entry=0xec923d70, nr_pages_scanned=1, lru_pages=3226603292, lru_pages@entry=52207) at mm/vmscan.c:326
#3  0xc00a3010 in do_try_to_free_pages (shrink=0xec923d70, sc=0xec923d78, zonelist=0xc0520830 <contig_page_data+2208> at mm/vmscan.c:2426
#4  try_to_free_pages (zonelist=zonelist@entry=0xc0520830 <contig_page_data+2208>, order=order@entry=64, gfp_mask=gfp_mask@entry=131290, nodemask=nodemask@entry=0x0)
    at mm/vmscan.c:2509
#5  0xc0097c24 in __alloc_pages_direct_reclaim (did_some_progress=<synthetic pointer>, migratetype=131290, preferred_zone=0x40, alloc_flags=2, nodemask=0x0,
    high_zoneidx=<optimized out>, zonelist=0xc0520830 <contig_page_data+2208>, order=0, gfp_mask=131290) at mm/page_alloc.c:2129
#6  __alloc_pages_slowpath (migratetype=131290, preferred_zone=0x1, nodemask=0x0, high_zoneidx=ZONE_MOVABLE, zonelist=0xc0520830 <contig_page_data+2208>, order=0, gfp_mask=131290)
    at mm/page_alloc.c:2351
#7  __alloc_pages_nodemask (gfp_mask=131290, order=order@entry=0, zonelist=0xc0520830 <contig_page_data+2208>, nodemask=nodemask@entry=0x0) at mm/page_alloc.c:2479
#8  0xc00b11a8 in __alloc_pages (zonelist=<optimized out>, order=0, gfp_mask=131290) at include/linux/gfp.h:302
#9  alloc_pages_node (order=0, gfp_mask=131290, nid=<optimized out> at include/linux/gfp.h:312
#10 __alloc_zeroed_user_highpage (vaddr=793632768, vma=0xecefd230, movableflags= at include/linux/highmem.h:192
#11 alloc_zeroed_user_highpage_movable (vaddr=793632768, vma=0xecefd230) at include/linux/highmem.h:214
#12 do_anonymous_page (flags=3221952572, pmd=0xecefd230, page_table=0xec1fc378, address=793632768, vma=0xecefd230, mm=0xec905c80) at mm/memory.c:3179
#13 handle_pte_fault (mm=mm@entry=0xec905c80, vma=vma@entry=0xecefd230, address=address@entry=793632768, pte=0xec1fc378, pmd=pmd@entry=0xec92cbd0, flags=flags@entry=41)
    at mm/memory.c:3484
#14 0xc00b183c in handle_mm_fault (mm=mm@entry=0xec905c80, vma=vma@entry=0xecefd230, address=address@entry=793632768, flags=flags@entry=41) at mm/memory.c:3598
#15 0xc0013c0c in __do_page_fault (tsk=0xec91c400, flags=41, fsr=2071, addr=793632768, mm=0xec905c80) at arch/arm/mm/fault.c:247
#16 do_page_fault (addr=793632768, fsr=2071, regs=0xec923fb0) at arch/arm/mm/fault.c:309
#17 0xc00083b0 in do_DataAbort (addr=793632768, fsr=2071, regs=0xec923fb0) at arch/arm/mm/fault.c:548
#18 0xc000dc74 in __dabt_usr () at arch/arm/kernel/entry-armv.S:410

nswcfd

估计inline和tail call(*)共同作用的结果。

(*)忘了具体的术语叫啥了，如果函数f1()的最后一条语句是函数调用（例如return f2())，
那么call f2可以用jmp f2来优化，其结果是在栈上没有f1的信息（在omit-frame-pointer的条件下）。

nswcfd

      -foptimize-sibling-calls
           Optimize sibling and tail recursive calls.

           Enabled at levels -O2, -O3, -Os.

nswcfd

回复 4# shihyu

方便给出gcc、gdb的版本信息，以及内核的具体编译选项么？（利用make V=1查看即可）

1. [test]$ cat Makefile
   
2. obj-m += aaa.o
   
3. all:
   
4.         make -C /path/to/kernel/source/root/ M=`pwd` V=1
   
5. 
   
6. [test]$ cat aaa.c
   
7. #include <linux/kernel.h>
   
8. #include <linux/module.h>
   
9. void myf(void) {}
   
10. EXPORT_SYMBOL(myf);
    
11. 
    
12. [test]$ make V=1
    

复制代码