4、断点设置基础：break命令、设置行号断点、设置函数断点、设置条件断点
调试多文件项目，说白了就是跟断点打交道。你想想看，没有断点，程序一口气跑到底，你根本不知道中间发生了什么。我个人习惯是，拿到一个崩溃的二进制，第一件事就是在可疑位置先下几个断点，然后再跑。
这一节我们聊聊最基础的断点设置。别小看这些命令，我见过不少工程师，用了好几年GDB，还在用最笨的方法下断点。其实这里头有不少门道。
4.1 break命令：最核心的武器
break（简写 b）是GDB里最常用的命令。它的作用很简单——告诉GDB：执行到某个位置时，停下来等我。
基本语法就一句话：
(gdb) break 位置
这个「位置」可以是行号、函数名、文件名+行号，甚至是地址。我平时用得最多的是 b 这个简写，敲起来快。
核心要点：断点一旦设置，只要程序执行到那一行，就会自动暂停。你可以查看变量、修改内存、单步执行，然后继续跑。
4.2 设置行号断点
行号断点是最直观的。比如你怀疑 main.c 的第42行有问题，直接：
(gdb) break 42
如果当前文件不是 main.c，那就得带上文件名：
(gdb) break main.c:42
嗯，这里要注意：行号必须是实际代码行，空行、注释行、大括号单独占一行那种，GDB会直接忽略。我曾经遇到过新手在空行上下断点，然后跑来问我为什么断不下来……
多文件项目里，我建议养成带文件名的习惯。因为GDB有时候会搞混当前上下文，尤其是你 step 进了别的文件之后。举个例子：
(gdb) b src/network.c:128
这样写，不管你在哪个文件里，断点都稳稳落在 network.c 的第128行。
小技巧：如果你不确定某一行有没有代码，可以用 list 命令先看看。GDB会显示附近的源码，你一眼就能判断该下在哪。
4.3 设置函数断点
函数断点更高级一点。你不需要知道行号，只需要知道函数名。比如：
(gdb) break main
(gdb) break handle_request
GDB会在函数的入口处停下来。注意，是入口处——也就是函数的第一行可执行代码，不是函数声明那行。
多文件项目里，不同文件可能有同名函数。这时候要带上文件名：
(gdb) break server.c:handle_request
如果函数是C++的，有重载，GDB会列出所有匹配的版本让你选：
(gdb) break MyClass::process
[0] cancel
[1] all
[2] MyClass::process(int)
[3] MyClass::process(double)
> 2
我个人习惯是直接写完整签名，省得它弹菜单：
(gdb) break MyClass::process(int)
避坑指南：我曾经在调试一个大型C++项目时，忘记加命名空间，结果断点下到了另一个同名函数上。排查了半天才发现。所以，C++项目里最好用 break 命名空间::类名::函数名 这种完整写法。
4.4 设置条件断点
条件断点是我最常用的功能之一。说白了就是：只有满足某个条件时，断点才触发。否则直接跳过。
语法很简单：
(gdb) break 位置 if 条件
举个例子，你有一个循环处理1000个请求，但第500个请求出了问题。你不想按500次 continue，对吧？
(gdb) break process_request if request_id == 500
这样GDB只在 request_id 等于500时停下来。其他999次，它默默跑过。
条件可以是任何合法的C/C++表达式。比如：
(gdb) break malloc if size > 1024
(gdb) break update_cache if strcmp(key, "user_token") == 0
(gdb) break write_log if fd == -1
你想想看，这比手动检查变量高效太多了。我记得有一次调试内存泄漏，我直接在 malloc 上下了一个条件断点，只拦截分配超过1MB的调用。几分钟就定位到了问题。
重要提醒：条件表达式里的变量，必须在断点所在的作用域内可见。如果变量不存在，GDB会报错，断点也不会生效。
4.5 断点管理：查看、删除、禁用
断点下多了，得学会管理。常用的命令就这几个：
| 命令 | 作用 | 示例 |
|---|---|---|
info breakpoints |
列出所有断点 | info b |
delete |
删除断点 | delete 2 删除编号2的断点 |
disable |
禁用断点（不删除） | disable 3 |
enable |
重新启用 | enable 3 |
clear |
清除某位置的断点 | clear main.c:42 |
我个人习惯是：调试初期大量下断点，然后逐步 disable 掉不需要的，而不是直接 delete。因为有时候你绕了一圈，发现还是最初那个断点有用。禁用了随时可以恢复。
小技巧：info breakpoints 的输出里，每一行最前面的数字就是断点编号。删除或禁用时用这个编号，不是行号。
4.6 多文件项目中的断点策略
多文件项目调试，断点不能乱下。我总结了一个简单的策略：
- 先下函数断点：在关键函数的入口处停下来，比如
main、handle_event、process_data。 - 逐步缩小范围：用
step和next单步走，找到可疑代码行。 - 下条件断点：如果问题只在特定输入下出现，用条件断点精准拦截。
- 禁用而非删除：保留历史断点，方便回溯。
举个例子，我曾经调试过一个网络服务，崩溃只在并发量超过1000时才出现。我直接在 accept_connection 函数上下了一个条件断点：
(gdb) b accept_connection if active_connections > 1000
然后配合 watch 命令监控某个变量的变化，半小时就找到了竞态条件。如果没有条件断点，我可能得盯着屏幕按一整天 continue。
4.7 本章小结
断点设置是GDB调试的基石。行号断点适合精确位置，函数断点适合入口拦截，条件断点则是高效调试的利器。多文件项目里，记得带上文件名，避免断点下错地方。
嗯，这一节的内容就这些。下一节我们聊聊更高级的断点技巧——比如硬件断点、数据断点、以及断点命令脚本。那些才是真正让你效率翻倍的东西。