常见的应用调试方法
一、常规调试方法：
（1）Printf和串口，在有终端的情况下使用printf打印调试；
（2）Led，在硬件上使用led作为程序的调试，查看程序的运行情况；
二、查询法：
获取有关文件系统支持，可用内存，CPU，运行程序的内核状态等信息 例如：查询 /proc 文件系统。
（1）/proc/cmdline -> 内核命令行
（2）/proc/cpuinfo -> 关于处理器的品牌，型号信息等
（3）/proc/filesystems -> 文件系统的内核支持的信息
（4）/proc/
（5）/proc/
（6）/proc/
三、跟踪法：
strace的和ltrace是两个在Linux中用来追踪程序的执行细节的跟踪工具。
1.Strace：系统调用
用来监控用户空间进程和内核的交互，比如拦截和记录系统调用 、信号传递、进程状态变更等。
它显示了系统调用、传递给它们的参数和返回值。当发现进程或服务异常时，我们可以通过strace来跟踪其系统调用，“看看它在干啥”，进而找到异常的原因 （更多的是用在运维的问题诊断）
工具的好处是不需要源代码，程序也不需要重新编译。
2.Ltrace：进程调用库函数的情况
首先ltrace打开elf文件，对其进行分析。在elf文件中，出于动态连接的需要，需要在elf文件中保存函数的符号，供连接器使用。 这样一来ltrace就能够获得该文件中所有函数调用的符号，以及对应的执行指令。然后ltrace将该指令所对应的4个字节替换成断点。 这样在进程执行到相应的库函数后，就可以通知到了ltrace，ltrace将对应的库函数打印出来之后，继续执行子进程。
常用指令：'-i' 选项在调用库时打印指令指针； '-S' 选项被用来现实系统调用和库调用。
实际上ltrace与strace使用的技术大体相同，但ltrace在对支持fork和clone方面，不如strace；strace在收到frok和clone等系统调用后，做了相应的处理，而ltrace没有。
四、Valgrind调试分析工具：
多用于检测内存泄漏、重释放、访问越界、使用未初始化的内存、内存读写越界（访问了不该访问或者没有权限访问的地址空间，动态内存访问时超出了申请的大小范围）、内存覆盖、使用已经释放了的内存等。
但是它增加了内存占用，会减慢程序。有时会造成误报和漏报。不能检测出静态分配的数组的访问越界问题。
常见的命令：valgrind --tool=memcheck --leak-check=full ./test
五、GDB：
给用户以控制权而去执行各种动作，例如：启动程序、停止在规定的位置、在指定条件下停止、检查所需要的信息、改变程序中的数据等。
1.原理：
（1）pc机：用GDB来调试ARM板上的程序,gdb程序需要带有调试信息的app文件；
（2）arm:有一个父进程gdbserver,这个gdbserver再去访问app内存空间 。
2.安装步骤：
（1）pc机安装gdb的步骤：
（2）编译GBD和gdbserver
（3）源码的下载：http://ftp.gnu.org/gnu/gdb/
（4）以下的所有目录在你解压之后打开的gdb源码目录中完成
tar xjf gdb...
gdb-7.4/
./configure --target=arm-linux
make
mkdir tmp
make install prefix=$PWD/tmp
cp /tmp/bin/arm-linux-gdb /bin（5）把arm-linux-gdb复制到/bin目录。
3.开发板安装的步骤：（将编译好的工具放在nfs的挂载目录下，然后开发板就可以使用）
cd ./gdb/gdbserver
./configure --host=arm-linux
cp gdbserver /home/zdh128/nfs_dir/rootfs_aston将拷过来的gdbserver文件放在开发板的/usr/bin 目录下 （库文件放在bin目录下）。
4.调试：
编译：编译要调试的应用，编译时加上-g选项，-g选项就是要加上一个调试信息。
arm-linux-gcc -g -o test_debug test_debug.c
cp test_debug /home/zdh128/nfs_dir/rootfs_aston/（1）在ARM板上：gdbserver 192.168.1.129:2345 ./test_debug
（2）在pc上：/bin/arm-linux-gdb ./test_debug
输入： target remote 192.168.1.129:2345
然后：使用gdb命令来控制程序
输入l：查看源码
输入break 打断点 break main 在main里面打断点
输入c：continue
break test_debug.c:31 在31行打断点
（3）通过core dump文件直接分析错误，进行调试：让程序在开发板上直接运行当他发生错误时，令它产生core dump文件然后使用gdb来根据core dump文件找到发生错误的地方。
①ulimit -c unlimited 不限制产生core dump文件的大小
②执行应用程序，错误发生时在当前目录下产生了名为core 的core dump文件。
在pc上： cp /work/nfs_root/../core . /bin/arm-linux-gdb ./test_debug ./core