在Linux上的gdb中加载核心文件时,如何预先加载目录库path

我有一个远程系统上生成的核心文件,我没有直接访问。 我也有来自远程系统的库文件的本地副本,以及崩溃程序的可执行文件。

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

例如:

gdb path/to/executable path/to/corefile 

我的库位于当前目录中。

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

如何在分析gdb中的corefile时指定首先从相对于当前目录的path加载库?

启动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解决方案。

我不确定这在gdb中是可能的,但是我不是专家。

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

 ldd path/to/executable 

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

 readelf -d path/to/executable | grep RPATH 
  • 如果该命令不打印,动态链接器将使用标准位置加上LD_LIBRARY_PATH环境变量来查找共享库。

  • 如果命令打印一些行,动态链接程序将忽略LD_LIBRARY_PATH并改为使用硬编码的rpath。

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

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

有关更多信息,您可以从以下开始:

 man ld.so 

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

 set solib-search-path path 

如果设置了这个变量,path是用冒号分隔的目录列表来搜索共享库。 solib-search-path' is used after solib-absolute-prefix'找不到库,或者库的路径是相对而不是绝对路径solib-search-path' is used after 。 如果你想使用solib-search-path' instead of solib-absolute-prefix,那么一定要把`solib-absolute-prefix'设置为一个不敏感的目录,以防止GDB找到你的主机的库。

编辑:

我不认为使用上面的设置prepends我添加的目录,但它似乎追加他们,所以从我目前的系统丢失的文件被拾取在我添加的路径。 我想将solib-absolute-prefix设置为伪造的,并按照我需要的顺序在solib-search-path中添加目录可能是一个完整的解决方案。

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

一个重要的说明:

如果您正在进行交叉编译并尝试使用gdb进行调试,那么在完成之后
file ECECUTABLE_NAME如果你看到file ECECUTABLE_NAME 。 喜欢 :

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

然后检查你的目标系统是否有libthread_db。 我在网上发现了很多类似的问题。 这个问题不能用“set solib-”来解决,你必须用你的交叉编译器来编译libthread_db。