调试思路

1. 程序中一定要尽可能的做容错处理，可能会出错的地方，增加打印日志，这样在出问题时候才能最快的定位问题，所以这个属于前置工作，前置做的越多越好，后期调试越省力，程序也更健壮。
2. 学会看日志信息（输出信息），好多新人最容易产生的心态就是一出问题，看到一堆英文的日志就慌了，不会甚至不敢静下心来先去读读什么意思，这是大忌，这种心态永远也不会成为高手。所以如果有日志，先不管你会不会调试，先别惧怕它，先尝试去读读，读不懂就帖到翻译软件去翻译，尝试着根据给出的信息做出分析，这也是和问题贴的最近的信息。
3. 多维度的分析问题，这个思想其实好多有经验的工程师也做不到。大多数人遇到一个问题后就会困在自己的思路里出不来了，很可能一开始选的路就是错的，那么沿着这个路继续下去不管你怎么折腾，最终一定是死胡同。所以如果一个问题卡了很久，查了很多资料，想了很多办法都解决不了，不妨先停下来，出去走走，抽一支烟，过程中想想抛掉固有的思想，换种思路说不定能柳暗花明。
4. 用好最简单的调试–打印，通过打印和日志基本能解决90%的问题，所以利用好打印信息，但是打印不要乱加，通常遵循以下几条规则：
   a. 加的打印一定要区分出位置，有些新人经常使用类似"---------"，"aaaaaaa"这种毫无意义的打印输出，到最后搞的到处都是这些日志，根本无法定位。所以增加的打印信息尽量有意义，带文件和行号是最好的。gcc有几个关键字能自动输出文件和行号，比如：

文件和行号的打印方法

printf("当前文件是[%s],当前行号是[%d]\n", __FILE__, __LINE__);

printf("当前文件是[%s],当前行号是[%d]\n", __FILE__, __LINE__);
b. 先根据逻辑分析，缩小问题范围，加打印不要到处都加，尽量先根据自己的逻辑或者按照二分法法则，在一些关键位置增加打印，一步步把问题定位到最小的范围，然后针对几句话去做分析，尤其是段错误这种问题。
c. 发布型产品通常都会带日志输出（打印是直接输入到终端的信息，日志通常指的是文件），因为一旦产品发布就没法通过终端的形式再获取到输出了，所以程序里一般会把一些关键的调试信息输出到日志文件中，以便出厂后问题分析。这种功能可以自己做，也可以利用一些现成的库，比如Linux自带的syslog就是一个非常好用的日志服务，感兴趣可以自己研究
5. 有些非常难找的问题，尝试使用专业的工具定位。

调试工具

首选当然还是开发平台自带的调试工具，官方的肯定是最好用的，比如Visual Studio的单步调试、QT的调试工具、Keil和Jlink或者STlink结合的硬件单步调试，都是非常强大的工具。

cppcheck

简介
这个工具是一个静态代码检查工具，适合写完代码还未运行时候先提前检查一些问题，使用起来比较简单。
Cppcheck_百度百科

rdynamic

简介
这个是gcc的一个选项，主要针对段错误定位的，配合gdb来使用能立马定位到段错误的行号。
教程
1

valgrind

简介
valgrind可以说是嵌入式开发调试的一款神器，不管是在虚拟机里开发还是在设备上开发，都可以使用，而且功能非常强大。
教程
2

CDT+GDB 图形化远程调试

简介
直接用gdb来调试代码其实不太好用，因为它是命令型的，所以效率相对较低，但是如果结合其它的工具，做成工具型的，再配合远程调试，那么在嵌入式Linux中调试效率基本可媲美Visual Studio的单步。
教程