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

来源:互联网 发布:剑网三大叔脸数据 编辑:程序博客网 时间:2024/03/29 03:39


开发调试中的办法非常多,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的启动日志的


0 0
原创粉丝点击