远程调试时符号文件必须在本地GDB加载，因gdbserver仅转发底层状态而不解析符号；所有源码级功能（如bt显示函数名、break按函数名设断点）均依赖本地symbol-file或add-symbol-file加载的匹配符号表，否则出现“??”和“No symbol matches”错误。
远程调试时符号文件必须在本地GDB里加载，不能靠目标机自动提供——这是最常被忽略的前提。
为什么 symbol-file 必须在本地执行
gdbserver 只负责转发内存、寄存器、断点控制等底层状态，它不解析符号，也不读取调试信息。所有源码级功能（bt 显示函数名、list 显示源码、break func 按函数名设断点）都依赖本地 GDB 加载的符号表。哪怕目标机上放着 program.debug，只要没用 symbol-file 或 add-symbol-file 告诉本地 gdb，它就完全“看不见”那些符号。
- 常见错误现象：
bt输出全是#0 0x000055... in ?? ()，info symbol 0x55...返回No symbol matches - 典型场景：调试嵌入式设备、安卓 native 进程、或客户现场的 core dump（无法拷贝整个文件回来）
- 关键点：本地 GDB 加载的可执行文件（
file ./program）和符号文件（symbol-file ./program.debug）必须与目标机上运行的二进制**完全一致**（校验md5sum或readelf -h的 build-id）
symbol-file 和 add-symbol-file 的区别与选择
两者都能加载调试符号，但适用条件完全不同：
-
symbol-file ./program.debug：直接替换当前符号表，适用于符号文件是完整 ELF（含 .text/.data/.symtab 等段）且加载地址已知的情况；它会清空之前加载的所有符号（包括 libc、动态库），慎用 -
add-symbol-file ./libsimple.so.debug 0x7f8a12345000：只追加符号，不覆盖已有符号；第二个参数是该模块在目标进程中的**实际加载基址**（从/proc/[pid]/maps或info sharedlibrary查得），适合动态库、内核模块等位置无关的符号加载 - 容易踩的坑：
add-symbol-file的地址必须是运行时真实地址，不是链接时的 VMA；若填错，bt仍显示??，且不会报错，只会静默失效
如何获取动态库的真实加载地址
远程调试中，动态库地址无法预设，必须从目标进程运行时提取：
- 方法一（gdb 内）：先
continue让程序跑起来，再执行info sharedlibrary，输出类似0x00007f8a12345000 0x00007f8a12346fff Yes (*) /path/to/libsimple.so，其中第一列就是基址 - 方法二（目标机上）：查
cat /proc/[pid]/maps | grep libsimple.so，取首行起始地址（如7f8a12345000-7f8a12346fff→ 基址为0x7f8a12345000） - 注意：
info sharedlibrary在未运行前为空；若程序崩溃后只剩 core dump，则需用gdb ./program core+info files查各段加载地址
libc 等系统库的符号怎么处理
libc 符号默认不可见，因为系统通常不装调试包。想看到 malloc、read 的源码和栈帧，得手动补全：
- Ubuntu/Debian：
sudo apt install libc6-dbg，然后set debug-file-directory /usr/lib/debug（gdb 自动查找） - 或下载对应版本的
glibc-source+glibc-debuginfo，解压后用add-symbol-file /path/to/libc-2.31.so.debug 0x7f8a12345000 - 关键提醒：libc 的基址每次启动都变（ASLR），必须每次重新查；若关闭 ASLR（
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space），基址才固定，但仅限调试环境
最麻烦的永远不是命令怎么敲，而是符号文件、可执行文件、目标进程三者 build-id 或 checksum 对不上——哪怕只差一个字节，bt 就会退化成地址列表。调试前花 30 秒校验 md5，能省掉两小时无意义排查。
