Native backtrace lib so库使用汇编进行分析错误位置-优快云博客

本文链接：https://blog.youkuaiyun.com/huifeidedabian/article/details/108349303

本文详细解析了一次ARM64架构下进程因SIGSEGV信号导致的崩溃现象，通过反汇编及符号定位，揭示了故障地址指向的内存读取错误，并提供了使用objdump和gdb调试的两种解决方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

(200901_13:43:21.574)[    3.854314]<3>[E](3)DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
(200901_13:43:21.574)[    3.859079]<3>[E](3)DEBUG: Revision: '0'
(200901_13:43:21.574)[    3.859791]<3>[E](3)DEBUG: ABI: 'arm64'
(200901_13:43:21.574)[    3.860438]<3>[E](3)DEBUG: pid: 1509, tid: 1530, name: xxxxxx
(200901_13:43:21.574)[    3.862246]<3>[E](3)DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7bfb083010
(200901_13:43:21.574)[    3.863512]<3>[E](3)DEBUG:     x0  000000000000003b  x1  0000007bf45013a0  x2  0000000000000001  x3  0000007b000a323e
(200901_13:43:21.574)[    3.865093]<3>[E](3)DEBUG:     x4  0000000000000018  x5  0000000000000038  x6  fefeff79ff09313d  x7  7f7f7f7f7f7f7f7f
(200901_13:43:21.574)[    3.866626]<3>[E](3)DEBUG:     x8  0000000000000002  x9  1c2825f020fa64b5  x10 00000000000001c5  x11 0000007bf90bd528
(200901_13:43:21.574)[    3.868258]<3>[E](3)DEBUG:     x12 000000000000003b  x13 0000000000000000  x14 00000000ffffffff  x15 0000007bf4500f08
(200901_13:43:21.574)[    3.869776]<3>[E](3)DEBUG:     x16 0000007bfa7feee8  x17 0000007bf9073760  x18 0000007bf450098a  x19 0000007bf8244200
(200901_13:43:21.574)[    3.871289]<3>[E](3)DEBUG:     x20 0000000000000018  x21 0000007bfa70f3e9  x22 0000007bfb083000  x23 0000000000000000
(200901_13:43:21.574)[    3.872928]<3>[E](3)DEBUG:     x24 0000000000000000  x25 0000007bf8244608  x26 0000007bfa70f420  x27 0000000000000000
(200901_13:43:21.574)[    3.874417]<3>[E](3)DEBUG:     x28 0000007bf8244558  x29 0000007bf4501490
(200901_13:43:21.574)[    3.875468]<3>[E](3)DEBUG:     sp  0000007bf4501400  lr  0000007bfa708a9c  pc  0000007bfa708ac0
(200901_13:43:21.574)[    3.884008]<0>[E](3)DEBUG: 
(200901_13:43:21.574)[    3.884013]<0>[E](3)DEBUG: backtrace:
(200901_13:43:21.574)[    3.884082]<0>[E](3)DEBUG:     #00 pc 0000000000005ac0  /vendor/lib64/libtest_debug.so (Test::debug(void*)+376)
(200901_13:43:21.636)[    3.884124]<0>[E](3)DEBUG:     #01 pc 0000000000083114  /system/lib64/libc.so (__pthread_start(void*)+36)
(200901_13:43:21.636)[    3.884163]<0>[E](3)DEBUG:     #02 pc 00000000000233bc  /system/lib64/libc.so (__start_thread+68)

在编译服务器中找到对应的so 库进行反汇编
PS: symbols 下面的objdump -dSCl 是可以将汇编代码和C代码放在一起的，方便根据汇编查询出错的C位置

./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/objdump -dSCl out/target../symbols/vendor/lib64/libtest_debug.so > aa.S

通过 aa.S 找到 pc 0000000000005ac0 对应的汇编位置

5ac0: ldr w4, [x22,#16]

将存储器地址为x22+16的字数据读入寄存器w4 中，而 x22 0000007bfb083000
0x7bfb083000 + 16 = 0x7bfb083010 ,这样就回到了出错的地方fault addr 0x7bfb083010

这样就可以知道这个是指针取值的时候错了，出差的位置在 5ac0 对应的C文件位置。
当前也可以使用简单的语句

addr2line -f -e libtest_debug.so 5ac0

打印文件和行号确定位置

对于kernel也可以使用addr2line vmlinux找到对应的KE位置

./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line -Cfe out/target../vmlinux  ffffff8008532ee8

方法二：
对于使用 ./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/aarch64-linux-android/bin/objdump 出现不能识别文件的时候可以使用 gdb 调试 so 库

./prebuilts/gdb/linux-x86/bin/gdb out/target/product/xxx/symbols/vendor/lib64/xxx.so
disassemble 0x5ac0