28

我在无法直接访问的远程系统上生成了一个核心文件。我还有来自远程系统的库文件的本地副本，以及崩溃程序的可执行文件。

我想在 gdb 中分析这个核心转储。

例如：

gdb path/to/executable path/to/corefile

我的库在当前目录中。

在过去，我看到调试器通过提供选项“-p”来实现这一点。或“-p /=。”；所以我的问题是：

在 gdb 中分析核心文件时，如何指定首先从相对于当前目录的路径加载库？

4

5 回答 5

47

在不指定可执行文件或核心文件的情况下启动 gdb，然后键入以下命令：

set solib-absolute-prefix ./usr
file path/to/executable
core-file path/to/corefile

您需要确保完全从目标系统镜像您的库路径。以上内容用于调试与您的主机不匹配的目标，这就是为什么复制包含库的根文件系统结构很重要的原因。

如果您正在远程调试与您的主机具有相同架构和 Linux/glibc 版本的服务器，那么您可以按照fd的建议进行操作：

set solib-search-path <path>

如果您尝试覆盖某些库，但不是全部，则可以将目标库目录结构复制到临时位置并使用上述solib-absolute-prefix解决方案。

于 2008-09-17T15:32:51.207 回答
4

我不确定这在 gdb 中是否可行，但我不是专家。

不过我可以评论Linux动态链接器。以下应打印所有已解析共享库和未解析共享库的路径。

ldd path/to/executable

我们需要知道您的共享库是如何与您的可执行文件链接的。为此，请使用以下命令：

readelf -d path/to/executable | grep RPATH

  • 如果命令不打印任何内容，动态链接器将使用标准位置加上 LD_LIBRARY_PATH 环境变量来查找共享库。

  • 如果该命令打印了一些行，则动态链接器将忽略 LD_LIBRARY_PATH 并使用硬编码的 rpaths。

    如果列出的 rpath 是绝对路径，我知道的唯一解决方案是将您的库复制（或符号链接）到列出的位置。

    如果列出的 rpath 是相对的，它们将包含一个 $ORIGIN，它将在运行时被可执行文件的路径替换。移动可执行文件或库以匹配。

有关更多信息，您可以从以下内容开始：

man ld.so
于 2008-09-17T15:56:45.750 回答
3

我在developer.apple.com上找到了这段摘录

set solib-search-path path

如果设置了此变量，则 path 是以冒号分隔的目录列表，用于搜索共享库。 solib-search-path' is used after solib-absolute-prefix' 找不到库，或者库的路径是相对的而不是绝对的。如果你想使用 solib-search-path' instead of solib-absolute-prefix'，请确保将 `solib-absolute-prefix' 设置为一个不存在的目录，以防止 GDB 找到你主机的库。

编辑：

我不认为使用上述设置会预先添加我添加的目录，但它似乎确实会附加它们，因此我当前系统中丢失的文件会在我添加的路径中被拾取。我猜想将 solib-absolute-prefix 设置为虚假的内容并按照我需要的顺序在 solib-search-path 中添加目录可能是一个完整的解决方案。

于 2008-09-17T15:48:36.240 回答
2

您也可以在调用 gdb 时将 LD_PRELOAD 设置为每个库或将 LD_LIBRARY_PATH 设置为当前目录。如果 gdb 本身尝试使用您预加载的任何库，这只会导致问题。

于 2012-10-02T15:09:11.877 回答
0

一个重要的注意事项：

如果您正在进行交叉编译并尝试使用 gdb 进行调试，那么在您完成之后，
file ECECUTABLE_NAME如果您看到 smth。像 ：

Using host libthread_db library "/lib/libthread_db.so.1"

然后检查您的目标系统是否有 libthread_db。我在网上发现了很多类似的问题。仅使用“set solib-”无法解决此类问题，您还必须使用交叉编译器构建 libthread_db。

于 2010-07-20T18:30:21.110 回答