Linux调试操作以及在编译器中的体现（GNU+GDB）

实际上在Vs里面写代码，直接点击一下编译运行即可，但是在Linux里面，额，不能说没有这样的编译器存在，只是那样似乎有点违背了使用Linux的初衷，因此，还是回归原始好点，使用终端命令

代码检查

出现错误的第一感，检查一下代码，但实际上在Vs里面，我们是看一下错误在哪，直接双击跳转或者是根据出错行数去找，这里实际上底层追根朔源要归结于GNU+GDB

cc -g -o debug1 debug1.c

虽然是Linux环境，但是，一个好的代码编辑器还是需要的，VsCode还是比较靠谱的，这里推荐一下

1.run

联想一下Vs里面的运行按钮即可，这个还是会报告出程序的出错位置的，就是没有编译器那么详细的功能设计

2.break断点、单步运行、变量值查看

(gdb)break 23
(gdb)run/cont
(gdb)print variable

本质就是集成编译器环境的断点运行状态，鼠标悬浮变量值查看操作，以及具体的单步运行等（every step for 1 break point maybe）

3.ctags\cxref\cflow

cxref可以理解为变量、符号、函数、#define定义等的查找命令，实际上一些好的代码编辑器的查找功能，你懂，是基于这个操作开发

cxref *.c *.h

PS：cxref不是GDB命令，是终端命令

cflow打印函数调用树，基本的程序框架可以很清楚的看出来，也集成于某些好用的代码开发环境和代码编辑器

cflow debug1.c

断言操作：

实际上，常规的代码（调试版）和发布版还是有很大差距的，至少发布版没有调试版那样的好用（对于开发者）

例如，断言操作，assert

sqrt(-2)||sqrt(2)

是否添加断言操作，这个程序的影响还是很大的

#define NDEBUG(before the "assert.h") for end

cc -o -DNDEBUG -debug1 debug1.c -lm

上述关闭断言的操作还是靠谱的，至少，用户程序利用捕捉操作，或是限制，一般卡死退出的可能性较小

取样调试操作：

这个实际上一直在用，只是，没有意识到有这样的一个名词定义

此外，标志位也是常用的调试操作，相信代码写的好的朋友都无形之中在用，只是不曾想过有这样的操作，自己不知情的情况下，完成了知识和经验的闭环，妙啊！