创作目的：归纳总结常用的技巧和方法，方便自己后续查阅重点节省时间。
一、仿真内核的gdb调试
1、新建DKM工程，选择sim的BSP包
2、DKM工程中添加c文件并编辑入口函数
3、新建vxworks远端系统
4、显示系统起来之后进行加载.out
5、选择Debug模式
6、选择自己写好的入口函数
7、设置相应断点后，点击下一步，遇到函数可以选择进入函数（stepover在函数内部断点调试），也可以退出函数（stepreturn），可以看到在shell界面出现了相应的打印。
8、attach调试相关任务
至此仿真内核的gdb调试完成基础搭建，后续可以自行结合vxworks中shell调试和gdb调试定位问题，gdb调试大幅度优化了解决问题的方法和手段，自己在项目开发阶段还是会使用sim核进行逻辑验证，本质上跑的应用程序没有什么区别，与硬件资源挂钩的部分，可能不便验证。
任务stop可以直接sp激活，接着调试，结合shell调试指令一起。
二、板载内核的gdb调试
与sim仿真内核极为相似，需要注意的是新建连接为Target server，
记得配置网卡ip(.50)和选择vxworks内核所在目录
此时并不需要在板卡的文件系统内部进行.out文件的下载，和启动文件的编辑，只需要在workbench集成环境下去加载.out到remote target即可，其余的与sim仿真核一样Debug方式也无明显的区别。
三、板级调试总结和注意事项：
1、任务挂掉或者触发异常记得设置开关量，用于查看和定位程序中的异常，来进行调试，删除or重启任务以及其他的调试指令。
2、可以在写应用程序的时候添加异常处理功能，重启任务or加入WTD，避免多次的重启板卡，使用d的功能级二行lookup查找验证。
3、任务调度验证条件可以固定，设置手动触发或者定时触发任务，不让任务一直pend，这样验证不了交互逻辑。
4、实际项目开发中除了DKM、RTP工程外额外搭建Sim的DKM工程，进行逻辑验证，使用close project功能可以避免多个c文件的干扰。也可以直接工程界面修改生成的.out名称，避免文件系统中启动文件的不固定。
5、实际中diab编译器和gnu编译器的配置也需要留意
6、如遇问题优先help手册