GDB启动时自动加载.gdbinit需满足路径信任条件：默认仅无条件加载$HOME/.gdbinit；若放项目目录，须提前用set auto-load safe-path注册该路径或使用--directory选项；加载成功可通过echo命令验证。
gdb 启动时自动加载 .gdbinit 的前提条件
GDB 只会在当前工作目录或用户主目录下查找并加载 .gdbinit，且**默认不读取当前目录下的文件**——这是最常被忽略的一点。从 GDB 10.1 开始，默认启用了安全限制：.gdbinit 若位于被调试程序所在目录（即“本地目录”），会被静默忽略，除非显式启用 --directory 或设置 set auto-load safe-path。
所以，不是“放了就能用”，而是必须满足路径信任条件：
-
.gdbinit放在$HOME下：无条件加载（推荐初学者首选） - 想放项目目录下？必须提前在可信路径中注册该目录：
set auto-load safe-path /path/to/your/project（可在$HOME/.gdbinit中设置） - 临时绕过限制（仅调试时）：
gdb --directory /path/to/project ./a.out，此时 GDB 会搜索该目录下的.gdbinit
如何验证 .gdbinit 是否真的被加载了
很多人改完脚本没效果，其实是加载失败但无提示。最直接的验证方式是在 .gdbinit 里加一句诊断输出：
echo [gdbinit] loaded successfully\n
然后启动 GDB，如果看到这行输出，说明加载成功；否则就是路径不对、权限问题或被安全策略拦截。注意：echo 命令只在 GDB 内部有效，不是 shell 命令。
立即学习“C++免费学习笔记（深入）”；
另一个关键检查点是命令是否语法合法：GDB 解析 .gdbinit 时遇到错误会停止执行后续命令，但不会报错。建议逐行测试，尤其是 define 自定义命令或 python 块——Python 语法错误会导致整块跳过。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
常见误用：source 和 -x 不等于自动加载
有人用 gdb -x ./my.gdb 或在 GDB 里手动 source ./my.gdb，这确实能执行脚本，但不符合“启动时自动加载”的需求，也无法触发 GDB 的 auto-load 机制（比如自动加载 libstdc++.so 的 Python pretty-printer）。
真正依赖 auto-load 的功能（如 STL 容器的可读显示）需要 GDB 在初始化阶段就识别并加载对应脚本，而这些脚本通常由系统库安装到 /usr/share/gdb/auto-load/ 下，并通过 .gdbinit 中的 add-auto-load-safe-path 或 set auto-load safe-path 授权访问。手动 source 无法激活这一整套机制。
一个最小可用的 $HOME/.gdbinit 示例
下面这段内容保存为 $HOME/.gdbinit（注意没有扩展名，且权限建议为 600）即可立即生效：
# 启用 Python 支持（多数现代 GDB 默认开启，但显式写上更稳） python import sys sys.path.insert(0, "/usr/share/gcc-12/python") # 根据实际 GCC 版本调整路径 end <h1>加载系统级 pretty-printer（Debian/Ubuntu 路径示例）</h1><p>add-auto-load-safe-path /usr/share/gdb/auto-load</p><h1>简单调试习惯设置</h1><p>set print pretty on set print demangle on set history save on</p><h1>定义常用别名</h1><p>define ll thread apply all bt end
注意路径 /usr/share/gcc-12/python 需按你系统中实际安装的 GCC 版本调整，否则 std::vector 等类型仍会显示为原始内存布局。不同发行版路径差异很大，CentOS 是 /usr/share/gdb/python，Arch 是 /usr/share/gdb/auto-load/usr/lib —— 具体得看 find /usr -name "*gdb*" -type d 2>/dev/null。
