方法论
当我们遇到问题，应该怎么办？这不仅应用于程序开发，也是我们在生活中遇到问题的时候，应该想的事儿，怎么办！趁着此次机会，我好好想了七秒钟。
- 先问是不是问题，如果不是就不用解决了
- 如果确实是问题，那就得先找到问题出现位置，也就是定位问题。怎么定位呢？缩小问题范围是一个办法
- 定位问题后，就得分析问题
- 最后，解决问题
也就是：问题->定位->分析->解决。我觉得吧，这些步骤，在程序开发中得调试，也是非常有趣的实践方法。
程序开发调试
软件开发过程中，总是经常出现不如意的结果，这个时候就要调试。 并且调试在软件生命周期中，会占用大量的时间，拥有非常大的时间跨度。
出现问题的现象很多，出现的阶段和种类也很多，比如编译阶段出错了，这时候就看编译报错信息就好了。这种错误一般容易解决。软件运行阶段异常了，这时候就需要寻找问题了。
可以通过点灯或者打印确定程序执行流程，得出执行在哪一部分出问题了。
可以通过打印变量等，来查看自己怀疑的点。以上都是比较简单的调试方法。
更多时候，我们更愿意使用调试工具，比如keil调试，gdb调试，jlink调试。可以查看执行流程，函数调用关系，栈信息，全局变量等。
OneOS与调试
上述说明了常见的调试，对OneOS专有的调试组件产生了很多好奇，毕竟调试占据了开发者大量的时间，如果有好的工具能极大地减少调试时间，那可真是太美妙了。
在OneOS有写道：提供控制台调试功能、查看系统状态功能，可帮助开发者进行故障定位，目前包括日志系统组件、shell控制台交互组件以及常用的故障定位组件。
控制台调试功能
先学习下控制台调试，其实就是shell命令行工具，提供了一套供用户在命令行调用的操作接口，主要用于调试或查看系统信息。在控制终端输入命令，控制终端通过某个通道(例如串口)将命令传给设备里的shell，shell会读取设备输入命令，解析并自动扫描内部函数表，寻找对应函数名，执行函数后输出回应，回应通过原路返回，将结果显示在控制终端上。
提供了很多的命令来查看系统信息，比如内存占用，任务信息，栈是否溢出等。
DLOG 日志系统
日志(log)是对发生某个事件的记录，并进行显示或者保存到文件。其实就是打印信息啦，但做了更多的封装，更多的功能。
支持 4 个等级，优先级由高到低 DLOG_ERROR DLOG_WARNING DLOG_INFO DLOG_DEBUG。更低的等级，可显示更多的信息。
这个日志系统，挺有趣的，如果出现问题了，我可能首先会选择使用shell命令行工具，以及把DLOG日志系统调整为DLOG_DEBUG。
eCoreDump组件
eCoreDump组件实现了嵌入式系统的coredump功能，记录当前程序的状态并打包成elf格式的corefile，可以配合gdb离线解析调用栈，查看临时变量。
感觉是对coredump做了整理和移植到OneOS上去了，这个调试功能可能不是开发阶段使用，而是部署软件后的使用，当在运行期间出现问题了，会生成eCoreDump文件，并保存在文件系统中，等到开发者从文件系统中拿出来，然后配合gdb来调试分析错误原因。
内存监测
通过调用mem_monitor_auto_init初始化自动监测，制定必要的内存地址，大小，检测方法，hash函数，以及回调，开始了自动监测，检测点是在任务切换中检测，看是否任务对此内存是否修改过。
有点意思噢，针对踩内存的问题，相信非常有用。
栈回溯
在系统运行或调试过程中，程序总是出现一些出乎意料的现象（例如程序异常或者某个任务运行不是预料的），为了帮助用户快速定位问题，解决用户定位问题难，在操作系统中添加了栈回溯功能。
栈中保存着函数的返回地址、局部变量等，那么我们可以从这些返回地址来确定函数的调用关系、调用顺序。我们通过栈回溯可以查看当前的上下文。
结尾
以上就是OneOS下调试支持的几种方式，通过menuconfig进行配置，我觉得自己受益良多，您呢？
(Top) → Components→ Diagnose Configuration
[ ] Stack back trace enable
[ ] Monitor CPU usage
[ ] Enable wireshark dump
eCoreDump --->
Memory Monitor --->