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

title image for user

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

代码检查

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

cc -g -o debug1 debug1.c
GDB for debug

VsCode for Linux

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

gdb command:

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
cxref for detail

PS:cxref不是GDB命令,是终端命令

cflow for lineseris

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

cflow debug1.c

断言操作:

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

例如,断言操作,assert

sqrt(-2)||sqrt(2)

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

#define NDEBUG(before the "assert.h") for end
cc -o -DNDEBUG -debug1 debug1.c -lm

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

取样调试操作:

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

example for this normal operation

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

发表回复

您的电子邮箱地址不会被公开。

召唤伊斯特瓦尔