条件断点需用c语法写比较表达式，如break main.c:42 if counter == 100；禁用赋值=，字符串用strcmp，指针判空用ptr!=0，结构体用全路径，避免函数副作用，优化编译下变量可能不可见。
条件断点里写变量比较表达式最常用
直接在 break 后加 if，GDB 会把后面整个当作 C 表达式求值。比如想在 counter 等于 100 时中断：
break main.c:42 if counter == 100
注意：这里用的是 C 语法，不是 shell 或 Python；== 是必须的，= 是赋值，会导致断点永远不触发（因为赋值结果非零）。
常见错误现象：break func if x = 5 看似想“当 x 是 5”，实际是把 5 赋给 x，每次命中都改值，且条件恒真——程序行为就乱了。
- 字符串比较不能用
==，得用strcmp(str, "target") == 0 - 指针判空写
ptr != 0或ptr（GDB 支持隐式转换） - 结构体成员要写全路径，比如
user->profile->age > 18
函数调用作为条件表达式要小心副作用
GDB 在每次命中断点前都会执行一次条件表达式，如果里面调用了有副作用的函数（比如修改全局状态、打印日志、malloc），会影响原程序逻辑，甚至导致崩溃或跳过关键路径。
典型场景：调试一个循环里的函数，想“第 5 次调用时停”，有人写 break func if ++call_count == 5——这会让 call_count 在每次检查时都自增，但函数本体还没执行，计数就偏了。
- 优先用只读表达式：比如检查循环变量
i == 7、检查数组索引idx >= len - 实在要计数，改用 GDB 内置命令：
ignore 1 4（忽略断点 1 的前 4 次命中） - 确认函数是否纯：不确定时，先在
print中试调，看返回值和副作用
条件断点中访问局部变量可能失败
不是所有作用域的变量在断点处都可见。优化编译（-O2）会让变量被寄存器复用或完全剔除，GDB 查不到 var 就报错 No symbol "var" in current context。
使用场景：你在 gcc -O2 编译的二进制里设条件断点，却发现变量名标红、条件无效。
- 调试阶段务必加
-g -O0（或至少-Og），否则条件断点大概率失效 - 用
info registers和info locals先确认变量是否在当前帧可访问 - 若变量不可见，退而求其次：用内存地址硬编码判断，比如
*(int*)0x7fffffffeabc == 42（不推荐，仅应急）
复杂条件建议拆成多个简单断点
写 if (a > 0 && b 看似没问题，但一旦某个子表达式出错（比如 <code>c 是野指针，解引用崩掉），整个条件求值失败，断点就静默失效——你根本不知道它没触发是因为条件为假，还是因为崩溃跳过了。
性能影响：GDB 每次都要解析并执行整条表达式，嵌套深、函数多时延迟明显，尤其在高频调用点。
- 拆成两个断点：
break file.c:100 if a > 0 && b 和 <code>break file.c:100 if c == 0 - 用
condition <num><expr></expr></num>单独修改已有断点的条件，避免重复输入行号 - 临时禁用某个条件断点用
disable <num></num>，比删了重设快
条件断点真正难的不是语法，而是搞清当前栈帧里什么变量存在、什么内存还有效、什么函数能安全调。写完别急着跑，先 print 几个关键值验证下上下文。
