总结调试过程中怎么去抓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的启动日志的