直接地址映射不可行，因gdb符号解析依赖内存布局、堆栈帧结构和动态库加载地址三者耦合，仅传地址列表无法重建崩溃上下文。
直接用 gdb 加载远程机器上的大 core 文件（几十 GB）到本地分析，基本不可行——不是命令不会用，而是 GDB 无法脱离原始崩溃上下文完成符号解析。
为什么不能把 core 文件拷到本地再 gdb？
因为 GDB 解析 backtrace 不是查表匹配地址，它依赖三个强耦合要素同时存在：
- core 文件里的实际内存布局（各段加载地址、堆栈帧结构、寄存器快照）
- 原可执行文件（含代码段布局、函数入口、重定位信息）
- 完整调试信息（
.debug_*段或分离的.debug文件），且必须与崩溃时的二进制严格一致
哪怕只换一个编译参数（比如 -O2 vs -O0）、改一行代码再重编，本地的 ./a.out 和远程崩溃时运行的就不是同一个二进制，bt 输出的函数名/行号大概率错乱甚至崩溃。
gdbserver 是怎么绕过传输 core 的？
gdbserver 本质是把“运行时状态访问”变成网络服务，不传数据，只传指令。流程是：
- 在目标机启动：
gdbserver :1234 --attach <pid></pid>（附加正在运行的进程）或gdbserver :1234 ./prog（直接启动） - 本地
gdb ./prog连过去：target remote target-ip:1234 - GDB 在本地解析符号，所有内存读取、寄存器读写、断点设置都通过 RSP 协议发给
gdbserver，由它在目标机现场执行并返回结果
所以你看到的 bt、info registers、x/10i $pc 全是实时从目标机拿的，完全不需要本地有那个 giant core。
真要分析已存在的远程 core，只能用 gdbserver 模拟“活进程”
核心技巧：用 gdbserver 把 core 当成“冻结的进程状态”来挂起，然后本地 gdb 连过去——这需要目标机还在线且能运行 gdbserver：
- 在目标机执行：
gdbserver --core /path/to/core :1234（注意：不是--attach，是--core） - 本地启动对应架构的 gdb（如
aarch64-linux-gnu-gdb），加载**原版可执行文件**：file ./prog - 连接：
target remote target-ip:1234 - 此时
bt、info proc mappings、info sharedlibrary全部可用，等效于在崩溃现场调试
⚠️ 前提：目标机上 gdbserver 版本需支持 --core（GDB ≥ 8.0），且必须用和崩溃时完全相同的可执行文件（readelf -h ./prog | grep BuildID 对得上）。
如果目标机已关机或无法运行 gdbserver？
只剩一个办法：把整个调试环境（可执行文件 + 调试信息 + core）打包拉回来，但别用普通 scp ——用 rsync --partial --progress 断点续传，或者走 ssh 管道压缩传输：
ssh user@target "cat /path/to/core" | gzip | dd of=core.gz
解压后，确保三件套齐全：./prog（带完整调试段）、/path/to/core、以及必要时的 sysroot（尤其涉及动态库时，用 set sysroot /path/to/sysroot）。最容易被忽略的是：core 文件里记录的动态库路径（如 /lib64/libc.so.6）在本地不存在，info sharedlibrary 会显示 No symbol table for ...，这时必须补全对应版本的 so 文件到 sysroot 下同路径。
