加载核心文件时，GDB 不会尝试加载任何共享库

Question

我正在创建一个流程，通过在嵌入式平台上启用核心转储来改进远程 LINUX 系统的调试。但在加载核心文件后，我无法让 gdb 从共享库加载符号。

我修改了我的 CI 构建系统，根据构建 ID 自动为所有二进制文件和库创建

--only-keep-debug

ELF 文件，这似乎是推荐的做法 - 除了目标的

--strip-unneeded

版本之外。

调试流程，

1. 生成自我造成的断言以触发目标上的核心文件，并复制回主机的 CWD。
2. 在 CWD 下的主机上重新创建目标系统文件结构 - 将剥离的二进制文件和必要的剥离的库复制到正确的位置。库的必要性通过解析（使用

   cross-comp-readelf --all core.a.out | grep,awk,sort,etc...

   ）自动确认，生成：

/lib/libfoo.so
/usr/lib/libbar.so

允许流程从 CI 存档自动创建：

CWD/sysroot/bin/a.out *stripped-binary-that-crashed*
CWD/sysroot/lib/libfoo.so *some-stripped-libraries*
CWD/sysroot/usr/lib/libbar.so *more-stripped-libraries*

3. 在 CWD$ path/to/cross-comp-gdb 中（在 strace -e open,openat -o st.log ... 下运行）

(gdb) set sysroot CWD/sysroot
(gdb) set solid-absolute-prefix CWD/sysroot
(gdb) file sysroot/bin/a.out
Reading symbols from sysroot/bin/a.out...
Reading symbols from CWD/.build-id/b5/9700de946784bbf2d65f9993145d14a3ba9a89.debug...
(gdb) core-file core.a.out
[New LWP 10226]
Core was generated by `a.out'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb661dd16 in ?? ()

4. gdb 不会尝试加载 libfoo.so 或 libbar.so...[由 strace st.log 确认]

(gdb) info sharedlibrary 
No shared libraries loaded at this time.

$ grep "libfoo" st.log
$

我已经确认 gdb 的 auto-solib-add 已打开，并且我还尝试了在任何 gdb 文档网站上可以找到的所有其他设置 - 例如 set auto-load safe-path /

但我无法理解为什么 gdb 在加载核心文件后不尝试打开和读取 libfoo.so 或 libbar.so 中的符号。

Answer 1

这个：

(gdb) info sharedlibrary

No shared libraries loaded at this time.

意味着GDB认为在生成

core

时没有加载共享库。

因此 GDB 没有理由寻找任何共享库。

根本原因是通常加载

(gdb) file ...

的二进制文件与实际产生核心的二进制文件之间不匹配。

您可以使用

eu-unstrip -n --core core.a.out

。这应该产生类似于

的输出

0x565481252000+0x5000 347372645d444e4437d8784840e889e3baaee2f0@0x565481252368 . . /tmp/t
0x7f3f0deb4000+0x1000 f782ff35a6a694d76861d9cef47136aefdb4d0f1@0x7f3f0deb4554 . - linux-vdso.so.1
0x7f3f0deb6000+0x332b8 f5fc74ba82d83f70b1e38b1d1c4172ade591d3b6@0x7f3f0deb6248 /lib64/ld-linux-x86-64.so.2 /usr/lib/debug/.build-id/f5/fc74ba82d83f70b1e38b1d1c4172ade591d3b6.debug ld-linux-x86-64.so.2
0x7f3f0dcb2000+0x1e3d90 3ddd476a0eddfeb6390b2791bd945afaa13978ff@0x7f3f0dcb2380 /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/debug/.build-id/3d/dd476a0eddfeb6390b2791bd945afaa13978ff.debug libc.so.6

关键是主二进制文件的build-id（上面的

/tmp/t

）与你的

sysroot/bin/a.out

的build-id相同（换句话说，它应该是

b59700de946784bbf2d65f9993145d14a3ba9a89

）。

如果构建 ID 不匹配，则说明您在某个地方犯了错误。

如果它们匹配，则说明您的跨 gdb 中存在错误。也许尝试更新的版本。