第2章：C++ 后端开发必备工具与调试

为什么调试不是“程序崩了再开 GDB”

服务器故障常发生在远端 Linux、优化构建、多线程/多进程、运行数小时之后。若上线时没有保存符号、build-id、source revision 与启动参数，core dump 只剩地址；若调试时没定义 signal/fork/thread policy，breakpoint 本身会改变调度，得到的“证据”可能与故障不同。

原书第 2 章把连接工具、构建系统、源码阅读和 GDB 放在同一章，因为调试起点不是命令，而是可复现环境。

后半章分别落实 GDB 调试多线程、GDB 调试多进程与调试 Nginx式 fork/worker 场景：每次停止都先确认 thread、inferior、signal 和 scheduler policy。

2.1 SSH、FTP 与远端操作边界

SSH/Xshell 用于 shell、port forwarding 和会话管理；文件传输应优先 scp/sftp/rsync 等基于 SSH 的方案。传统 FTP control/data channel 默认无加密，不应用于传输 credentials、core dump 或 production config。

ssh -L 16379:127.0.0.1:6379 user@server
scp build/server.sym user@server:/srv/symbols/
rsync -av --checksum config/ user@server:/srv/app/config/

进入机器后先收集 pwd、ulimit -a、environment、ps、binary checksum/build-id，再 attach；直接覆盖线上 binary 或随意复制 library 会破坏证据。

2.2 Makefile 与 CMake：debuggability 在构建时决定

Make 判断 timestamp/dependency 后执行 recipe；header dependency 若未自动生成，修改 header 可能留下 stale object。常用 compiler depfile flags 或让 CMake/Ninja 管理。

add_executable(server main.cpp session.cpp)
target_compile_features(server PRIVATE cxx_std_17)
target_compile_options(server PRIVATE
  $<$<CONFIG:RelWithDebInfo>:-fno-omit-frame-pointer>)

现代 CMake 把 include path/definitions/options 绑定到 target 和 visibility，不用全局 flags 污染所有 modules。单配置 generator 用 CMAKE_BUILD_TYPE，多配置 generator 在 build 时用 --config；混用会让你以为启用了 Debug 实际没有。

cmake -S . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build -j
readelf -n build/server | grep "Build ID"
file build/server

-g 生成 DWARF，optimization 会 inline/reorder/eliminate variables；strip 删除 binary 内 symbols/debug sections。production 可部署 stripped binary，但必须按 build-id 保存未剥离 symbol artifact。core、binary、symbols 和 source 必须来自同一次 build。

2.3 Visual Studio 管理与阅读大型源码

Visual Studio solution/project 可用于 Windows build/debug，也可只作为 source navigator。导入开源项目时应以真实 CMake/compile database 为 source of truth；IDE 自建 include/macro 若与 CI 不同，会出现“IDE 能跳转/编译，服务器构建失败”。

cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

源码阅读先从 process entry、event loop、ownership type 和 call sites 建图，再借 IDE Find All References/Class View；不要只沿文件树顺序阅读。

2.4 GDB 启动、参数与停止条件

gdb --args ./server --config server.conf --port 9000
(gdb) show args
(gdb) run

也可 set args 改参数；attach 用 gdb -p PID，core 用 gdb ./server core。attach 会暂停 process，生产环境先评估 watchdog/traffic impact。

break、tbreak、condition 与 commands

(gdb) break Session::on_read if fd_ == 42
(gdb) tbreak main
(gdb) info breakpoints
(gdb) disable 3
(gdb) commands 1
> silent
> printf "fd=%d\n", fd_
> continue
> end

tbreak 命中一次后自动删除；condition 缩小高频 handler；commands 可自动打印/continue，形成低干预 probe。breakpoint 添加失败时检查 function 是否 inline、symbol 名称/namespace、shared library 是否加载，以及 binary 是否带符号。

backtrace、frame、list、print 与 ptype

(gdb) backtrace full
(gdb) frame 2
(gdb) info args
(gdb) info locals
(gdb) list
(gdb) print session
(gdb) ptype Session

先固定 thread/frame，再读变量；否则你可能在错误 context 解释同名 local。set print elements 0 可完整显示 string/array，但巨大 buffer 会拖慢 GDB；先看 length/header，再按范围打印。

2.5 执行控制：next、step、until、finish、return、jump

continue 跑到 breakpoint/signal/watchpoint；finish 跑到当前 function return；until 运行到 source line 或跳出当前 loop；return 强制当前 frame 返回；jump 改 instruction pointer。后两者会跳过正常 side effects/cleanup，只适合实验假设，不能把修改后的行为当原始故障证据。

(gdb) disassemble /m Session::on_read
(gdb) info registers
(gdb) x/32xb buffer.data()

高优化下 source line 不再一一对应 instructions，local 可能 <optimized out>。此时结合 disassembly、register、memory 和 inlining 信息，不把跳行误判为 debugger defect。

2.6 watch、display、dir 与动态库源码

(gdb) watch session.state_
(gdb) rwatch buffer.size_
(gdb) display /x errno
(gdb) dir /workspace/source
(gdb) set substitute-path /build/agent/src /workspace/source

watchpoint 比在所有 writers 下断点更直接，但 object move/free 后 address 含义会变；范围过大可能退化 software watch 并极慢。dir/substitute-path 只修 source lookup，不会修 binary-symbol mismatch。

2.7 多线程调试：先确认 selected thread

(gdb) info threads
(gdb) thread 7
(gdb) thread apply all bt
(gdb) set scheduler-locking step

thread apply all bt 是 deadlock 首证据：找哪些 threads 持锁/等待，沿 lock order 建 wait-for graph。scheduler-locking step 只在单步时限制其他 threads，能降低噪声也会改变 race/timing；复现 race 时应先保存无干预 evidence，再选择性冻结。

2.8 多进程、fork 与 signal

(gdb) set follow-fork-mode child
(gdb) set detach-on-fork off
(gdb) info inferiors
(gdb) inferior 2
(gdb) handle SIGPIPE stop print nopass

follow-fork-mode 决定 fork 后 selected parent/child；detach-on-fork off 保留两者供切换。调 Nginx 等 master/worker 时，先确认 breakpoint 属于哪个 process 与 module。

服务器常故意处理 SIGPIPE/SIGTERM/SIGUSR1。若 GDB 吞掉或额外停止，行为会变化；用 handle 明确 stop/print/pass。调用 function、set variable、return/jump 都会改变 inferior，更改前记录 backtrace/register/memory。

2.9 GDB TUI、cgdb 与 VisualGDB

layout src、layout asm、layout regs、focus cmd 用于切换窗口；显示未刷新可 redraw。cgdb 提供更强 source navigation，但底层调试语义仍是 GDB。VisualGDB 把远端 Linux build/attach 与 Visual Studio UI 连接，适合团队已用 VS；必须校验 remote binary/symbol/source mapping，不把 GUI 绿色箭头当证据来源。

.gdbinit/Python extensions 很有价值，但项目配置来自不可信目录时不要自动 source；调试脚本可以执行 code，需纳入版本与 review。

三步建立可复现调试证据

小结

• SSH/FTP 工具首先是远端证据边界；生产 artifact、symbols、source 与 build-id 必须匹配
• Makefile/CMake 决定 targets、dependencies 与 compile flags；RelWithDebInfo 常兼顾线上相似性和可调试性
• Visual Studio/IDE 应消费真实 CMake/compile_commands，不能另造一套宏与 include truth
• GDB 先固定 stop condition、thread/frame，再读取 variables；next/step/continue/finish/watch 语义不同
• optimized code 需结合 disassembly/register/memory，source line 和 locals 不保证一一保留
• 多线程先采集 all-thread backtrace；多进程明确 follow-fork/detach/inferior；signals 明确 stop/print/pass
• GDB TUI、cgdb、VisualGDB 是前端，不能替代 matching artifacts 与 context

名词解释