总结调试过程中怎么去抓log

开发调试中的办法非常多，LOG是其中重要的一个方法，一些常见的LOG的抓取办法（主要针对QUALCOMM平台，未经详细整理）：


1.ADB查看或保存kernel的启动LOG:
kernel log: adb shell dmesg > d:\kerneltestlog.txt


tips :dmesg -n 8               //设置log的等级
#define KERN_EMERG"<0>"/* system is unusable*/
#define KERN_ALERT"<1>"/* action must be taken immediately*/
#define KERN_CRIT"<2>"/* critical conditions*/
#define KERN_ERR"<3>"/* error conditions*/
#define KERN_WARNING"<4>"/* warning conditions*/
#define KERN_NOTICE"<5>"/* normal but significant condition*/
#define KERN_INFO"<6>"/* informational*/
#define KERN_DEBUG"<7>"/* debug-level messages*/


dmesg -s 81920              //设置LOG的Buffer,默认的buffer是8192


2.smem log:
    1>、用trace32。trace32无疑是强大的，几乎可以做任何debug的事情，有高通代码的兄弟可以在\AMSS\products \76XX\tools\debug目录下找到smemlog.cmm和smem_log.pl这两个文件，可以dump出log.
Run “do tools\debug\smemlog.cmm” from Trace32
Run “perl smem_log.pl > smemlog.txt”


    2>、没有trace32的兄弟也不要灰心，google为我们提供了强大的adb工具。命令如下：
    adb shell
    mkdir /data/debug
    mount -t debugfs debugfs /data/debug
    cd /data/debug/smem_log
    cat dump_sym
   可以给大家看一下抓下来的部分log
   
3.各种log（实际也包括第1种kernel的启动日志）：
很多人经常搞不清楚各种日志文件的作用，什么时候抓这些文件，其实如果你分不清楚的话
               最好一起抓了，至少你要分清楚有哪些日志文件需要抓。

    log文件分为实时打印的，还有状态信息的两种

实时打印的主要有：logcat main，logcat radio，logcat events，tcpdump，还有高通平台的还会有QXDM日志


    状态信息的有：adb shell dmesg，adb shell dumpstate，adb shell dumpsys，adb bugreport


    讲解一下各自作用：


    通过DDMS抓的其实跟用dos批处理抓的一样都是logcat的日志文件，ddms抓的通常是main缓存中的，就是应用程序打印的日志文件。不过 ddms好处在于能够实时看到带有颜色的，如果是用dos批处理只能重定向到文件，到抓完之后才能够看到，不是实时的。
    DDMS是调试应用的最重要的一个LOG工具了。


    adb logcat -b main -v time>app.log  打印应用程序的log


    adb logcat -b radio -v time> radio.log 打印射频相关的log，SIM STK也会在里面，modem相关的ATcommand等，当然跟QXDM差的很远了。


    adb logcat -b events -v time  打印系统事件的日志，比如触屏事件。。。


    tcpdump 是很有用的，对于TCP/IP协议相关的都可以使用这个来抓，adb shell tcpdump -s 10000 -w /sdcard/capture.pcap，比如抓mms下载的时候的UA profile，browser上网的时候，使用proxy的APN下载，streaming的相关内容包括UA profile等。


    最后是高通平台的QXDM，不管是不是Android，只要使用高通芯片，都会对它很熟悉，当然了，不是高通的芯片就不用提它了。这个不多讲，内容丰富，射频，电话，上网，...凡是高通提供的解决方案，这个都可以抓。


    状态信息：其实一个就够了，那就是bugreport（命令adb bugreport>bugreport.log)。里面包含有dmesg，dumpstate和dumpsys。dmesg（命令adb shell dmesg > ldmesg_kernel.log）是kernel的log，凡是跟kernel相关的，比如driver出了问题（相机，蓝牙，usb，启动，等等吧）。 dumpstate是系统状态信息，里面比较全，包括手机当前的内存信息、cpu信息、logcat缓存，kernel缓存等等。adb shell dumpsys这个是关于系统service的内容都在这个里面，这个命令还有更详尽的用法，比如db shell dumpsys meminfo system是查看system这个process的内存信息。


还有其他的比如PV的log，一般都是开发人员自己写的，可能让你放到sd卡里面，其他的不足或需要补充的期望您的指导。




   
4.查看用户空间的WAKELOCK:
cat /sys/power/wake_lock


cat /proc/wakelocks

5.MODEM端的LOG最主要的是QXDM，这个用QUALCOMM平台的人都知道；
手机在MODEM端crash时的QXDM LOG的获取通过如下办法
crash F3 log:
To get F3 trace from Trace32
1>.Run recover_f3.cmm or getf3trace.cmm with Trace32 connected or the Trace32 Simulator when the appropriate ELF/ramdump is loaded
2>.Run “perl FormatTrace32F3Trace.pl trace0001.txt > f3.txt”; this generates a nicer looking f3.txt than raw trace0001.txt


To get F3 trace from trace data stored to EFS
1>.Get the file of F3 saving from EFS by using QPST EFS Explorer
err_f3_index00.F3for MSM6xxx
apps_err_f3_index00.f3, modem_err_f3_index00.F3for MSM7xxx
2>.Run recover_f3.cmm or process_efs_trace_file.cmm
3>.Run “perl FormatTrace32F3Trace.pl trace0001.txt > f3.txt”


test 1>.run trace32 simulate,load elf,do do recover_f3.cmm
2>.perl FormatT32F3Trace.pl f3tokens.txt msg_hash.txt > f3log.txt    (Linux,windows should intall perl.)(QSRMessageHash.qsr as msg_hash.txt)



上面都是直接可以使用的LOG获取办法；另外还有一些LOG的获取办法需要自己稍微修改，只列举几个我曾经使用过的例子。
1.LCD,这个是在bootloader使用的。
      在MODEM或Android的APPSBL里面可以直接写LOG到LCD，这个需要自己转换字库点阵到位图，还有位图到LCD的画屏。
      在Linux的kernel也可以指定console到LCD。直接查看kernel的启动LOG。
2.FLASH文件系统，这个使用当然必须在文件系统OK后。这个我是在USB失效时，或者遇到抓取一些不能使用USB条件的LOG：
       MODEM端可以写LOG文件到EFS。
       linux端可以写LOG文件到SD卡。
3.串口。这个我也是把linux kernel的console指定到qualcomm的hs uart2上，抓取kernel的启动日志的