AndroidT(13) -- 根据 native appliction 的crash报告定位源码位置(一)

1.概览

  native application在Android中一般指代无需虚拟机参与就可以运行的可执行程序。例如c/c++开发的一众HAL服务，但是像手机应用则不是naitve程序了，因为它是需要art虚拟机参与的。native appliction 在性能上一般是高于需要虚拟机运行的程序的。
  本小节聚焦如何根据 crash 所给的报告来定位在源码中具体的行数，使用的工具就是 addr2line 。但是由AOSP编译的源码并不像pc中那般直接，不论是符号表、编译工具链都不是很好确定，所以在此做个总结。

2.编译工具链的确认 – addr2line

  假设在AOSP环境下单独编译了native 应用程序 logPrintCppStyle

flagstaff@fakeserver:~/AOSPT/test/flagstaff/logging_test/logPrintCppStyle$ mmm . -j23
...
[100% 10/10] Install out_board_t_userdebug/target/product/board/system/bin/logPrintCppStyle
1
2
3

  AOSP编译系统的功能非常的完善，在对应的out目录下可以找到编译过程中的所有日志，对于编译工具链的路径信息可以在文件 verbose.log 中找到

flagstaff@fakeserver:~/AOSPT/out_board_t_userdebug$ gzip -d verbose.log.gz
flagstaff@fakeserver:~/AOSPT/out_board_t_userdebug$ vi verbose.log
[1/6] PWD=/proc/self/cwd ~/AOSPT/prebuilts/clang/host/linux-x86/clang-r450784d/bin/clang++ -c ... 
    -o logPrintCppStyle.o logPrintCppStyle.cpp
1
2
3
4

  可见AOSP编译系统使用的编译工具连为 clang++，这里也就可以根据clang++所在路径找到一整套的编译工具链了

flagstaff@fakeserver:~/AOSPT/out_board_t_userdebug$ ls ../prebuilts/clang/host/linux-x86/clang-r450784d/bin/
bisect_driver.py  clang-format      ld64.lld        llvm-addr2line   llvm-cxxfilt    llvm-modextract  llvm-readelf     merge-fdata
clang             clang++.real      ld.lld          llvm-ar          llvm-dis        llvm-nm          llvm-readobj     remote_toolchain_inputs
clang++           clang.real        lld             llvm-as          llvm-dwarfdump  llvm-objcopy     llvm-size        sancov
clang-14          clang-tidy        lldb            llvm-bolt        llvm-dwp        llvm-objdump     llvm-strings     sanstats
clang-check       clang-tidy.real   lldb-argdumper  llvm-cfi-verify  llvm-lib        llvm-profdata    llvm-strip       scan-build
clang-cl          dsymutil          lldb.sh         llvm-config      llvm-link       llvm-ranlib      llvm-symbolizer  scan-view
clangd            git-clang-format  lld-link        llvm-cov         llvm-lipo       llvm-rc          llvm-windres
1
2
3
4
5
6
7
8

  在此也就找到了工具 addr2line，下面就可以使用它来定位错误信息了

flagstaff@fakeserver:~/AOSPT/out_board_t_userdebug$ ls ../prebuilts/clang/host/linux-x86/clang-r450784d/bin/llvm-addr2line
../prebuilts/clang/host/linux-x86/clang-r450784d/bin/llvm-addr2line
1
2

3.查找符号表

  在AndroidT中，真正放到板子上运行的可执行程序是不含调试信息的，这也就是为什么不从真机中直接pull上来。在AndroidT中符号表会被拷贝到如下位置

//板子中直接运行的可执行程序
flagstaff@fakeserver:~/board/out_board_t_userdebug$ ls target/product/board/system/bin/logPrintCppStyle -l
-rwxrwxr-x 1 flagstaff flagstaff 11608 11月 28 13:32 target/product/board/system/bin/logPrintCppStyle
//带调试信息的可执行程序
flagstaff@fakeserver:~/board/out_board_t_userdebug$ ls target/product/board/symbols/system/bin/logPrintCppStyle -l
-rwxrwxr-x 1 flagstaff flagstaff 133408 11月 28 13:32 target/product/board/symbols/system/bin/logPrintCppStyle
1
2
3
4
5
6

  可见这俩大大小还是差距很大的。
  实际上，此处符号表的位置并不是编译工具链生成的，而是脚本拷贝过来的，编译工具链编译生成的也可以从 verbose.log 中获取

//verbose.log
prebuilts/clang/host/linux-x86/clang-r450784d/bin/clang++ 
...
@out_board_t_userdebug/soong/.intermediates/test/flagstaff/logging_test/logPrintCppStyle/logPrintCppStyle/android_arm64_armv8-2a_cortex-a76/unstripped/logPrintCppStyle.rsp 
...
-o
out_board_t_userdebug/soong/.intermediates/bionic/libc/crtend_android/android_arm64_armv8-2a_cortex-a76/obj/bionic/libc/arch-common/bionic/crtend.o -o out_board_t_userdebug/soong/.intermediates/test/flagstaff/logging_test/logPrintCppStyle/logPrintCppStyle/android_arm64_armv8-2a_cortex-a76/unstripped/logPrintCppStyle
1
2
3
4
5
6
7

4.工具错误pc值获取源码错误位置

  下面先看下crash的报告信息，这部分信息可以从logd中获取，也可以从对应的tombstone文件中获取

backtrace:
    #00 pc 0000000000053274  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164) (BuildId: 2909e25171905ab2aa55000ddb487289)
    #01 pc 00000000000063fc  /system/lib64/liblog.so (__android_log_default_aborter+12) (BuildId: ea3eb93b960dede93d1fb67c42ed7273)
    #02 pc 0000000000016a50  /system/lib64/libbase.so (android::base::LogMessage::~LogMessage()+352) (BuildId: 805c1dfe4ea9454d03b5d1626665b3f0)
    #03 pc 00000000000015dc  /system/bin/logPrintCppStyle (main+1404) (BuildId: 595d8e1f7c1fa7fb8eb9b557fcd93d9b)
    #04 pc 000000000004b650  /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 2909e25171905ab2aa55000ddb487289)
1
2
3
4
5
6

  backtrace则是来自crash报告的一个片段，对于满足本章的需求已经足够了。定位挑选自己的代码部分就可以，可知crash发生时，我们的代码运行到了

#03 pc 00000000000015dc  /system/bin/logPrintCppStyle (main+1404) (BuildId: 595d8e1f7c1fa7fb8eb9b557fcd93d9b)
1

  pc后面的数值为十六进制，也就是程序指针。下面就可以用它和符号表来定位源码行数信息了

//logPrintCppStyle
flagstaff@fakeserver: ~/board/prebuilts/clang/host/linux-x86/clang-r450784d/bin/llvm-addr2line 15dc  -e logPrintCppStyle  -f -a -s -p
0x15dc: main at logPrintCppStyle.cpp:136 (discriminator 8)
//logPrintCppStyle.cpp
        main
            ...
line:136    LOG(FATAL)<<"LOG(FATAL):write log";
1
2
3
4
5
6
7

  可见测试代码中使用 fatal 级别的 log 来触发 native 应用 crash 的位置为第136行。
  下面是 llvm-addr2line 的配置信息
    -e:Path to object file to be symbolized (if not provided, object file should be specified for each input line)
    -f:Print function name for a given address
    -a:Show address before line information
    -s:Strip directory names from paths
    -p: Make the output more human friendly