save breakpoints filename.txt 可保存所有断点（含条件、状态、位置）为可读可编辑的纯文本文件，source 后可完整恢复；其他调试命令需用 -x 脚本手动组织，history save 不可靠。
gdb 里怎么保存断点和调试命令到文件
直接用 save breakpoints 命令就能把当前所有断点写入文本文件，后续可复用。它不保存你敲过的 print、next 等临时命令，只存断点（含条件、文件行号、禁用状态等），这是最常用也最可靠的持久化方式。
-
save breakpoints filename.txt：生成纯文本，内容可读、可编辑、可 git 跟踪 - 断点文件里会保留
enable/disable状态，source filename.txt后原样恢复 - 如果用了
set args或环境变量，这些**不会**被保存——得单独记在文档或写 wrapper 脚本 - 别用
history save：它导出的是 GDB 内部命令历史（含q、help这类无意义条目），格式混乱，基本没法重放
想回放一整套调试操作（比如复现 bug 步骤）
用 -x 批处理模式 + 自定义脚本文件。GDB 本身不录“操作录像”，但你可以手动把关键命令整理成脚本，再用 gdb -x script.gdb ./program 自动执行。
- 脚本里写标准 GDB 命令，每行一条：
set args --verbose、break main、run、bt - 支持
echo和注释（以#开头），方便说明每步意图 - 注意：脚本中不能有交互式命令（如
next后停住等你按回车），必须靠continue或finish控制流程 - 调试中途崩溃？加
set follow-fork-mode child和set detach-on-fork off防止子进程跑丢
core dump 分析时如何避免重复设置环境
分析 core 文件时，每次都要重新 set solib-search-path、dir 源码路径、set environment，手动输极易出错。解决方案是把它们全写进一个初始化脚本，启动时自动加载。
- 建
gdbinit-core，内容示例：set solib-search-path /path/to/libs dir /path/to/src set environment LD_LIBRARY_PATH=/path/to/libs file ./myapp core core.12345
- 然后运行：
gdb -x gdbinit-core，一步到位加载符号、源码、库路径、core - 别把配置塞进全局
~/.gdbinit：不同项目依赖路径冲突，反而增加干扰 -
show configuration可确认当前生效的路径和环境，比凭记忆靠谱
为什么不能 rely on history save
history save 导出的是 GDB 的内部命令缓冲区快照，不是调试逻辑记录。它混着大量无意义输入（比如打错的 prin、q、help break），且不含上下文（哪个断点触发了哪次 bt）。真要复现问题，靠这个等于翻聊天记录找答案——信息密度低，还容易漏关键步骤。
真正需要留痕的，永远是「意图」：在哪设断点、为什么设、期望看到什么。这些必须人工提炼进 save breakpoints 或 -x 脚本，而不是依赖自动记录。
