.gdbinit文件加载顺序为：当前目录./.gdbinit优先，其次用户主目录~/.gdbinit，最后系统级；文件需纯gdb命令，支持set confirm off、set pagination 0等配置，但source脚本需前置set script-extension off防解析错误。
gdbinit 文件位置和加载顺序
gdb 启动时会自动查找并执行 .gdbinit 文件，优先级从高到低是：./.gdbinit（当前目录）→ ~/.gdbinit（用户主目录）→ 系统级（极少用，不建议碰）。只要文件存在且可读，gdb 就会逐行执行其中的命令。
注意：.gdbinit 必须是纯 gdb 命令文本，不能混写 shell 或 python 语法（除非你明确配置了 script-extension）。
set confirm off 和 pagination 0 这类基础配置怎么写
这类命令直接写进 .gdbinit 即可生效，无需额外包装。常见组合包括：
-
set confirm off：避免每次删除断点、退出时弹出 “y/n” 提示 -
set pagination off（或set pagination 0）：禁用分页，防止bt或info registers卡住 -
set print pretty on：结构体打印更易读 -
set history save on：保存命令历史到~/.gdb_history -
set follow-fork-mode child：调试 fork 后的子进程（默认是 parent）
示例 ~/.gdbinit 片段：
set confirm off set pagination 0 set print pretty on set history save on set follow-fork-mode child
source 自定义脚本时为什么报错“undefined command”
错误现象通常是：source my-commands.gdb 报 Undefined command: "my_command"，但该命令在交互式 gdb 中明明可用。
根本原因是：gdb 默认用 script-extension 的 soft 模式解析脚本，遇到 .gdb 或无扩展名文件时，可能误判为 python 脚本（尤其当文件以 # 开头或含空行时）。
解决办法只有两个：
- 显式关闭脚本扩展识别：
set script-extension off（加在.gdbinit最前面） - 或统一用
.gdb扩展，并确保内容全是合法 gdb 命令（不写任何 python 语法）
别依赖后缀自动识别——它不可靠，尤其在跨环境部署时。
带参数启动程序的配置怎么固化
不能把 run --arg1 val1 直接写进 .gdbinit，因为 run 只在程序已加载后才有效，而 .gdbinit 是在 gdb 初始化阶段执行的，此时还没 file 或 exec-file。
正确做法是用 set args 预设参数，它不依赖程序是否已加载：
set args --config=config.json --verbose- 再配合
file ./myapp或启动时gdb ./myapp，之后run就自动带参
如果想一键启动+带参+自动断点，可以用 -x 加载临时脚本：
echo -e "b main\nset args --test\nrun" > /tmp/auto.gdb gdb -x /tmp/auto.gdb ./myapp
但这种不属于 .gdbinit 配置范畴，属于一次性调试流。
真正容易被忽略的是 script-extension 的默认行为——它让看似简单的 source 变得脆弱。哪怕你只写一行 set confirm off 在 my.gdb 里，不加 set script-extension off，在某些 gdb 版本上就可能静默失败。
