OneOS下调试支持的几种方式

方法论

当我们遇到问题，应该怎么办？这不仅应用于程序开发，也是我们在生活中遇到问题的时候，应该想的事儿，怎么办！趁着此次机会，我好好想了七秒钟。

先问是不是问题，如果不是就不用解决了
如果确实是问题，那就得先找到问题出现位置，也就是定位问题。怎么定位呢？缩小问题范围是一个办法
定位问题后，就得分析问题
最后，解决问题

也就是：问题->定位->分析->解决。我觉得吧，这些步骤，在程序开发中得调试，也是非常有趣的实践方法。

程序开发调试

软件开发过程中，总是经常出现不如意的结果，这个时候就要调试。并且调试在软件生命周期中，会占用大量的时间，拥有非常大的时间跨度。

出现问题的现象很多，出现的阶段和种类也很多，比如编译阶段出错了，这时候就看编译报错信息就好了。这种错误一般容易解决。软件运行阶段异常了，这时候就需要寻找问题了。

可以通过点灯或者打印确定程序执行流程，得出执行在哪一部分出问题了。

可以通过打印变量等，来查看自己怀疑的点。以上都是比较简单的调试方法。

更多时候，我们更愿意使用调试工具，比如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  --->