核心答案：gdb通过加载的带调试信息的elf文件（如u-boot）中嵌入的.debug_line等段提供的地址映射表，将崩溃地址0x00a12f80查表定位到main.c第856行；无此elf文件则无法映射。
崩溃地址是0x00a12f80，怎么对应到main.c第856行？
核心答案：GDB自己不“知道”源码位置，它靠你提供的带调试信息的ELF文件（./myprogram）里嵌入的地址映射表来翻译。没有这个ELF文件，0x00a12f80就只是个无意义的十六进制数。
实际操作中必须满足三个条件：
- 用
-g编译出的可执行文件（不是.bin或被strip过的版本） - 该文件未被修改、重命名，且与生成
core时运行的是同一个二进制 - GDB加载时明确指定这个ELF文件：
gdb ./myprogram ./core.1234，不能只写gdb ./core.1234
一旦满足，GDB启动后会自动读取ELF中的.debug_line等段，把崩溃地址映射到源文件+行号。你看到的at main.c:856就是查表结果。
bt输出全是??()，说明栈帧损坏，还能定位吗？
能，但得绕开bt，直接查内存。栈帧损坏时，rbp（或fp）寄存器和栈上保存的返回地址可能还残留有效值。
关键命令组合：
-
info registers rbp—— 看当前栈底指针在哪 -
x/10xg $rbp—— 从rbp开始向下读10个8字节（x64），找疑似返回地址的值（通常在0x00000000004xxxxx范围内） -
addr2line -e ./myprogram -f -C 0x0000000000401234—— 把猜到的地址喂给addr2line反查函数名和行号
注意：addr2line必须用和core同源的带-g的ELF，否则输出为??。
为什么用交叉GDB时总提示“No symbol table is loaded”？
这不是GDB的问题，是你的ELF文件本身没调试信息，或者架构不匹配。
检查三件事：
- 确认编译命令含
-g，且没跟-s或strip：运行file ./myprogram，输出里必须有with debug_info - 确认交叉GDB版本和目标CPU一致：ARM32程序不能用
aarch64-linux-gnu-gdb，会加载失败；反过来也不行 - 确认ELF是目标平台可执行格式：
readelf -h ./myprogram | grep -E 'Class|Data|Machine'，对比你的交叉工具链支持的ABI
常见错误：用x86_64主机上的gdb直接打开ARM程序，报错但不提示原因——必须用gdb-multiarch或对应交叉GDB。
崩溃信号是SIGABRT，但bt显示在__GI_abort，怎么找真正出问题的地方？
SIGABRT通常是“症状”，不是“病因”。glibc在检测到堆损坏（如double free、use-after-free）后主动调用abort()，所以栈顶永远是__GI_abort。
真正线索藏在崩溃前的日志和内存状态里：
- 先看
info signals SIGABRT确认是否被屏蔽或处理过 - 用
thread apply all bt检查其他线程是否在做内存操作 - 用
info proc mappings看堆地址范围，再用x/20xg 0x7ffff7a00000（举例）抽查可疑内存块内容 - 最可靠办法：复现时加
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc_malloc_debug.so或用AddressSanitizer重新编译，它会在真正破坏点报错
别在__GI_abort里打转——它只是守门员，破门的是前面某个函数。
