必须使用匹配目标架构（如aarch64-linux-gnu）的交叉编译GDB，x86版GDB无法解析ARM寄存器/指令，会导致“Target description specified unknown architecture”等错误；符号文件须与目标二进制ABI及Build ID严格一致，并通过set sysroot或set solib-search-path正确配置符号路径。
交叉编译 GDB 必须匹配目标架构
用 x86 版本的 gdb 直接调试 ARM 程序，会报错或无法解析寄存器/指令，因为架构不匹配。必须使用为你的目标平台（如 aarch64-linux-gnu 或 arm-linux-gnueabi）交叉编译的 GDB 二进制。
常见错误现象：
-
Cannot access memory at address 0x...（地址空间不可读） Target description specified unknown architecture "aarch64"-
Remote 'g' packet reply is too long（协议解析失败）
验证当前 GDB 支持的架构：gdb --version 输出末尾应含 aarch64-linux-gnu 或类似字样；也可运行 gdb -ex "show architecture" -ex quit 查看。
符号文件必须与目标二进制 ABI 和 build ID 严格一致
即使 GDB 架构对了，若符号文件（.debug、.so、.elf）不是用同一套工具链、同一份源码、同一轮 make 编译出来的，info symbol 可能显示函数名但 list 无法出源码，断点也打不到行号上。
关键检查项：
- 目标程序是否带
-g编译：如aarch64-linux-gnu-g++ -g -O0 main.cpp -o main - 动态库是否同时生成了调试包（如
libxxx.so.debug）且路径正确 - 执行
readelf -n ./main | grep BuildID和readelf -n /path/to/libxxx.so | grep BuildID，确保 Build ID 完全一致
gdbserver 启动时需显式加载符号路径
在目标设备上运行 gdbserver 本身不加载符号，它只转发内存/寄存器状态；符号解析完全由主机端 GDB 负责。所以主机 GDB 必须提前知道从哪找符号。
推荐做法（在启动 GDB 前执行）：
set solib-search-path /path/to/target/root/lib:/path/to/cross/toolchain/aarch64-linux-gnu/libc/usr/lib-
set sysroot /path/to/target/root（指向整个目标根文件系统镜像，含/usr/lib/debug等） - 若符号嵌入在可执行文件中（Debug 模式），直接
file ./main即可；否则需symbol-file ./main.debug
注意：set sysroot 会影响所有后续 sharedlibrary 加载行为，且优先级高于 solib-search-path。若 sysroot 下没有对应库，GDB 会静默跳过，不报错也不加载。
动态库符号延迟加载与 add-symbol-file 的时机
程序未运行时，info sharedlibrary 显示的库是“已知但未加载”，此时 add-symbol-file 无效。必须等程序启动、库被动态链接器真正映射进内存后，才能用其加载地址补符号。
典型流程：
- 在主机端：
target remote :1234连上gdbserver - 在目标端：
gdbserver :1234 ./main（或 attach 已运行进程） - 主机端执行
continue让程序跑起来，再info sharedlibrary找到libxxx.so的From地址（如0x7ffff7dd1700） - 然后：
add-symbol-file /path/to/libxxx.so.debug 0x7ffff7dd1700
容易漏掉的点：如果 libxxx.so 是用 -fPIE 编译的，加载地址每次不同，必须每次重新查 From 地址再 add-symbol-file；不能硬编码。
