pending断点是GDB在符号未就绪时的延迟绑定机制，常见于未加载共享库、启动前初始化函数或stripped二进制场景；需等待动态库加载或显式加载后，通过info breakpoints查看address是否变为有效地址来确认生效。
pending断点是GDB找不到目标符号时的临时占位
当你在GDB里执行 b foo 却看到 Function "foo" not defined. Make breakpoint pending on future shared library load? (y or [n])，选 y 后显示 Breakpoint 1 (foo) pending.——这说明GDB当前无法解析 foo 的地址，但它记下了这个请求，等后续动态库加载进来再自动补全。这不是错误，是GDB对延迟绑定场景的正常应对。
什么情况下会触发pending状态
常见于以下三类场景，本质都是符号地址尚未可知：
- 断点打在还未加载的共享库函数上（如
libcrypto.so中的SSL_connect） - 断点设在主程序启动前就需触发的初始化函数（如
__libc_start_main或_init） - 调试 stripped 二进制时，符号表缺失，GDB仅靠函数名无法定位（此时即使库已加载，也可能持续 pending）
pending断点能用吗？怎么确认它是否生效
可以，但得等条件满足。GDB会在以下时机尝试解析：
- 执行
r（run）后，动态链接器加载共享库时 - 手动执行
sharedlibrary libxxx.so显式加载库 - 命中同名符号的其他上下文（比如该函数被内联或出现在多个编译单元中）
用 info breakpoints 查看：如果状态列显示 pending，address 列为空或为 <PENDING>，说明还没就绪；一旦 address 变成有效内存地址（如 0x00007ffff7bca0b0），就表示已成功绑定。
容易忽略的关键细节
pending 断点不会自动重试失败的解析，也不会在 reload 或 exec-file 后自动刷新。如果你改了二进制、换了库路径、或用了 set solib-search-path 却没生效，GDB仍可能卡在 pending 状态而不报错。最稳妥的做法是：在 r 前确认 info sharedlibrary 已列出目标库，且 info functions foo 能搜到符号——否则别指望 pending 会自己“醒来”。
