解析dump的几种方式

在开发调试过程中，经常会遇到手机/设备crash或者dump了，memory dump是分析系统crash/dump的重要办法

在qualcomm的流程中，设备如果发生dump，会将dump的log缓存到某一个区域，用户可以利用个别工具将log取出来分析，以下就是基本qcom的基础上介绍几种获取dump log的方法：

1.T32方法

trace32 onlie软件，链接到主板/设备上，然后利用JTAG方法能获取到log，T32的方法适用于qcom和MTK各种平台，具体方法可以google T32查询，这里不重点不在T32的方法

2.利用QPST获取

手机在dump后，会进入一个特殊的端口模式（diag.9006 Port），手机此时并不是处于关机/待机状态，这时候打开QPST Configuration，手机会自动抓取dump log并导出。同时，可以在phone状态栏发现，手机处于sahara memory dump的状态下。如下：

然后对应的文件夹会存放到指定的QPST目录下，默认目录在：

C:\Program Files\Qualcomm\QPST\....

在QPST中有设置输出路径的地方，DUMP LOG. 存储路径为 ：

点击 Help 菜单 第二项 Open Log File Directory ,在弹出的窗口中打开Sahara 文件夹中 ，其中Port_COMX文件夹内存放的就是DUMP LOG, 注意此处 Port_COM号跟之前在QPST Configuration软件中显示COM 号要一致。以确保是本次导出

注意的是：

1.在链接QPST导出时，请关系其他占用端口的软件，例如QDST等等，否则可能会导致QPST无法连接串口

2.QPST软件最好在window下运行，在虚拟机的window中运行有时候也会发生未知的错误链接不到

××××××××

获取到dump的log后，此时的log是无法直接review的，还需要经过处理，拿到ramdump+vmulinux，放在同一个路径下

脚本请下载：linux-ramdump-parser-v2/ramparse.py

git clone git://codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools

以上工具是需要区分32位和64位的，请注意环境

同时在android环境中找到ndk提供的交叉编译环境：arm-linux-androideabi-gdb和arm-linux-androideabi-nm（也可以在网上下载）

执行以下cmd：

python /data/doc/linux-ramdump-parser-v2/ramparse.py --force-hardware=8916 -v/data/Port_COM49/vmlinux -g /data/p445tf/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gdb -n /data/p445tf/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-nm -a /data/Port_COM49 -o /data/dump8 –x

以上， 红色部分：ramparse.py脚本路径

    绿色部分：平台信息

    浅紫色部分：vmlinux路径

    深紫色部分：交叉编译环境路径，目前的路径就是gcc环境编译后存放在位置

    深黑色部分：dump文件名

以上是为了举例解释脚本用法，最好是添加到~/brasch中，方便快捷

其中-v指定dump文件对应的带调试信息的内核vmlinux文件
       -g指定对应的gdb工具文件
       -o指定解析文件的输出目录
       -x表示所有的debug信息均输出

命令执行后会出现如下解析info

!!! Out directory does not exist. Creating...


    [1/32] --clock-dump ... 0.873911s
    [2/32] --cpr3-info ... 0.135361s
    [3/32] --cpr-info ... 1.103903s
    [4/32] --cpu-state ... 0.098867s
    [5/32] --ddr-compare ... 3.923111s
    [6/32] --check-for-watchdog ... 0.011697s
    [7/32] --parse-debug-image ...
    ...

等待大约8分钟后，会提示解析完成，然后可以打开分析，dump log全部解析完成

3.利用高通QCAP网站解析

首先，你得有高通账号！你得有高通账号！你得有高通账号！（同时qcom那边有贵司项目信息入库）重要的事情说三遍

QCAP网站：

https://cap.qti.qualcomm.com/default.aspx

进入后是如下界面，界面中保存着你所有解析过的dump文件的记录，甚至可以下载xml下来给高通帮忙分析

那么要使用这个网页工具，点击new start analysas，会进入下面的页面：

按照图上的信息填完，carsh log就是dump log的路径

而build location这选择contents.xml路径，该文件存放在nonhlos/或者amss/下，用于区分modem侧各个分区的信息，会依照此文件分别解析对应log

解析完成后会显示如下界面：

首页会有网页自动帮忙分析的root case，当然解决问题的办法还需要深入的去查看其中的详细log（左侧可以分别查看tz，modem，ap侧等各类log和存储堆栈信息）

奇怪的是，个别log本地解析会有异常，没有log吐出，如果有case在qcom帮忙分析的话，qcom会重新要一份这样的vmlinux，dump file等拿去自己解析（据说他们解析出来文件是完整的）