GDB本身不调试死循环，真正调试依赖带-g编译的程序；若run后卡住，需Ctrl+C中断并检查是否缺失调试符号或优化过高。
直接结论：GCC本身不调试死循环，真正干活的是GDB——但必须用GCC带-g编译，否则GDB连变量名都看不到。
为什么gdb ./a.out启动后run就卡住？
这不是GDB坏了，而是程序真正在CPU上跑着空转。GDB默认不会主动中断运行中的程序，你得手动按 Ctrl+C 触发信号，让GDB接管控制权。这时GDB会停在当前执行点，通常是死循环体内的某一行（比如while(1)或for(;;)括号后）。
- 如果按
Ctrl+C没反应，检查是否启用了handle SIGINT nostop noprint——重置为handle SIGINT stop print即可 - 某些嵌入式环境或容器里
Ctrl+C被拦截，可改用kill -INT $(pidof a.out)从外部发信号 - 若GDB显示
Program received signal SIGINT, Interrupt.但停在汇编指令而非C源码行，说明没加-g或优化级别太高（如-O2），行号信息丢失
backtrace输出一堆#0 0x... in ?? ()怎么办？
这是符号表缺失的典型表现。GDB找不到函数名和调用栈上下文，往往因为：
- 编译时漏了
-g：确认命令是g++ -g -O0 main.cpp -o main，不是g++ main.cpp -o main - 链接时strip掉了符号：检查是否执行过
strip ./main，或者Makefile里有$(STRIP) $(TARGET)这类操作 - 动态库未加载调试信息：用
info sharedlibrary看GDB是否识别到所有so，缺失的需安装libxxx-dbgsym包（Ubuntu/Debian）或debuginfo-install（CentOS/RHEL）
怎么定位死循环里“卡住”的变量？
不能只靠print i看循环变量，很多死循环根本不动它——比如等待硬件标志位、阻塞在read()、或指针越界改写了邻近变量。关键动作是：
- 停住后立刻用
info registers看rip（x86_64）或pc（ARM）指向哪条指令，再用x/10i $pc反汇编周围代码 - 对疑似条件变量设观察点：
watch sensor_ready，GDB会在该变量被修改时自动中断（注意：仅支持内存地址可追踪的变量，局部寄存器变量不行） - 检查循环退出条件是否被破坏：比如
while (ptr != nullptr)，用print ptr确认值，再用x/4xb ptr看指针指向内存是否合法 - 若怀疑数组越界导致循环变量被覆写，用
info frame查栈帧范围，再用x/20wx $rsp看栈上相邻变量值是否异常
为什么step进不去函数，next却直接跳过整段？
这通常不是操作错误，而是编译器优化把函数内联了。GDB无法单步进入已被展开的代码块，next自然“跳过”。解决方法只有两个：
- 重新编译：加
-O0禁用优化，确保函数保持独立调用结构 - 接受现实：用
disassemble看汇编，结合源码逐条对照指令，重点盯cmp/je/jne等跳转指令的条件判断逻辑
特别注意：Release版本下while(1)可能被优化成jmp .L2这种纯跳转，GDB显示的“当前行”可能永远停在循环开头——这时候watch和info registers比单步更有效。
