info functions和info variables列出已加载的函数与全局/静态变量名，info address则验证符号是否存在并返回地址；三者需结合使用，且依赖调试符号正确加载。
直接看 info symbol 不行，它只查单个地址；真正能列出当前已加载符号集合的命令是 info functions、info variables 和 info address 的组合，但它们各有局限——info functions 只显示函数名（不带地址），info variables 仅限全局/静态变量，而 info address 才是唯一能确认“gdb 是否真认得这个符号”的实锤手段。
用 info functions 和 info variables 看符号名列表
这两个命令输出的是 gdb 当前符号表里“已知的函数”和“已知的变量”名字，前提是调试符号已成功加载（即启动时看到 Reading symbols from ...）。
-
info functions列出所有函数符号，包括静态函数（以文件名前缀区分），但不显示地址或类型 -
info variables列出所有全局/静态变量，同样无地址信息；局部变量需用info locals，且仅在栈帧有效时可用 - 若输出为空或远少于预期，大概率是没带
-g编译，或符号被 strip 过，或调试文件路径不匹配
用 info address 验证某个符号是否真被加载
info address 是最可靠的“存在性检查”：它不依赖符号是否可见于源码上下文，只要符号在当前符号表中注册过，就会返回地址和所在节（section）。
- 查函数：
info address main→ 返回类似Symbol "main" is at 0x401100 in a file compiled without debugging. - 查变量：
info address counter→ 若返回地址，说明该变量符号已就位；若报Symbol "counter" not found.，则未加载或作用域不可见 - 注意：即使符号名存在，若其地址落在未映射内存或 ASLR 偏移未对齐，
info address仍会返回地址，但后续x或print可能失败
为什么 nm/readelf 看到的符号，gdb 却不认？
因为 gdb 加载符号依赖的是 ELF 中的 .symtab（静态符号表）或 .debug_* 节（调试信息），而不是 .dynsym（动态符号表）——后者只供运行时链接器使用，gdb 默认忽略。
- 用
readelf -s binary | grep main看到T main，不代表 gdb 能调试它；得确认readelf -S binary | grep debug有 .debug_* 节，或nm -C binary输出含main且非U（undefined）类型 - 共享库符号需显式加载：
add-symbol-file /path/to/lib.so 0x7ffff7a00000（地址从/proc/pid/maps查），否则info functions不会包含它内部的函数 - strip 后的二进制即使保留
.dynsym，info functions也基本为空——gdb 不从那里读函数名
符号加载状态的快速判断法
别依赖 “有没有报错”，要看三处输出是否一致：
- 启动 gdb 时第一行是否含
Reading symbols from ...（不是Reading symbols from ... (no debugging symbols found)） -
info target中的Symbols from行是否指向有效的文件路径（而非none） -
maint info symtabs是否列出非空的 symtab 条目（这是内部符号表结构，有即表示已解析）
这三个地方有一处断链，info functions 就不可信。最容易被忽略的是：你改了编译参数重新生成 binary，却忘了 gdb 还连着旧进程或旧 core 文件——此时 info functions 显示的仍是旧符号快照。
