问题标签 [elf]

假设我有一个库libfoo.so.1，它（根据ldd）依赖于libbar.so.1. 但是，libbar.so.1目前不可用。我的应用程序需要调用一个libfoo.so.1根本不需要的函数libbar.so.1。

有没有办法加载libfoo.so.1、解析函数符号然后调用它而不必libbar.so.1满足依赖关系？这是一个“我知道我在做什么，让我已经做”的案例。我尝试了 RTLD_LAZY 标志，但它仍然尝试在不加载符号libbar.so.1之前加载库。

编辑

这是确切的情况。

我们有3名球员：

• libbar.so.1, 位于不在LD_LIBRARY_PATHor中的路径中的共享库ldconfig，并且其依赖关系都已解决
• libfoo.so.1，一个共享库，位于与 不同的目录中libbar，但取决于libbar. 在运行时，libfoo会知道在哪里定位libbar.
• App，一个二进制应用程序，需要libfoo在运行时的某个时间点加载。

App不知道在哪里可以找到libbar，但知道libfoo知道。我想要完成的是拥有一个 init 函数，libfoo其中只需将App' 的当前工作目录更改libbar为最终解决所有依赖项并使每个人都开心的位置。

libfoo最终需要调用 in 的东西，libbar而不是在这个 init 函数中。我不认为创建存根会起作用，因为符号最终需要解析为实际功能。

我的 Linux 系统 (Fedora 9) 上的所有标准共享库都将 ELFOSABI_NONE (0) 指定为它们的 OSABI。

这很好 - 但是我从供应商那里收到了一个共享库，其中 ELF 标头中给出的 OSABI 是 ELFSABI_LINUX (3)。

对于用于 Linux 系统的共享库来说，这听起来并不是一个不合理的值，但是它与我所有其他库的值不同 - 所以当我尝试使用 dlopen() 从一个在我的其他库中，这失败并出现错误“ELF 文件操作系统 ABI 无效”。

我编译了 FreeBSD 实用程序brandelf.c并使用它将 OSABI 类型更改为 0，现在该库似乎可以与其他所有内容一起使用。

我只是想知道 - 为什么你认为这个库被标记为 ELFOSABI_LINUX？我猜也许他们在另一个系统上交叉编译并指定了一些 gcc 标志，导致这个值被设置到 ELF 标头中？我试图实现类似但无法确定适当的 gcc 标志或标志。

我想知道可能的原因是什么，因为这个特定的供应商在没有很多手的情况下不会做任何事情，我想说“你可能正在做 X，但这意味着我们必须修改你的库在我们收到它们之后”。

我的意思是单个二进制文件可以在 Win32 和 Linux i386 中运行吗？

我已经为代码生成器编写了一个接口，可以让我生成共享对象。虽然我不想实现对节头表的支持，因为这是 ELF 文件格式的主要复杂性所在。

GNU ld 使用节头来链接共享对象。这意味着当我尝试将 gcc 链接放在没有节标题的共享对象上时，它将失败，因为 ld 找不到符号，即使它们存在于库中。

是否存在一些技巧可以用来欺骗编译器以使链接成功，即使它找不到某些符号？

以下是有关问题的一些说明：

我在术语上很少混淆。

作为链接器输入的文件称为Object File。链接器生成一个Image 文件，该文件又用作加载程序的输入。

我从“MS PE & COFF Specification”得到这个

Q1。图像文件也称为Binary Image，Binary File或简称为Binary. 对？

Q2。因此，根据上述术语，PE/ELF/COFF 是图像文件而不是目标文件的格式。对？但是http://www.sco.com/developers/gabi/latest/ch4.intro.html说

本章介绍目标文件格式，称为 ELF（可执行和链接格式）。目标文件主要分为三种类型。

• 可重定位文件包含适合与其他目标文件链接以创建可执行文件或共享目标文件的代码和数据。

• 可执行文件包含适合执行的程序；该文件指定 exec(BA_OS) 如何创建程序的进程映像。

• 共享对象文件包含适合在两个上下文中链接的代码和数据。首先，链接编辑器 [参见 ld(BA_OS)] 处理共享对象文件与其他可重定位和共享对象文件以创建另一个对象文件。其次，动态链接器将其与可执行文件和其他共享对象结合起来，以创建进程映像。

矛盾的是，他说目标文件和图像文件都是 ELF 格式，他根本没有区分目标文件和图像文件，而是通常将它们称为目标文件。是不是错了？

Q3。我知道PE源自COFF。但是为什么微软PE格式规范被命名为Microsoft Portable Executable《通用对象文件格式规范》。他们还支持COFF吗？如果他们，在哪个操作系统中？我以为PE很久以前就完全取代了COFF。

执行时，程序将从虚拟地址 0x80482c0 开始运行。这个地址并不指向我们的main()过程，而是指向一个_start由链接器创建的过程。

到目前为止，我的谷歌研究只是让我做出了一些（模糊的）历史推测，比如：

民间传说 0x08048000 曾经是 STACK_TOP（即堆栈从 0x08048000 附近向下增长到 0）在 *NIX 到 i386 的端口上，这是由加利福尼亚州圣克鲁斯的一个团体颁布的。当时 128MB 的 RAM 很昂贵，而 4GB 的 RAM 是不可想象的。

任何人都可以确认/否认这一点吗？

How to track code using ARM ELF? Which tools we have to use?

有很多 PE 文件浏览器。如果您有兴趣，这里有一个好的列表：

PE 文件格式查看器：

• PE 资源管理器http://www.pe-explorer.com/
• PE 视图：http: //www.magma.ca/~wjr/
• PEBrowse Professional http://www.smidgeonsoft.prohosting.com/pebrowse-pro-file-viewer.html
• PE 浏览专业互动 - http://www.smidgeonsoft.prohosting.com/pebrowse-pro-interactive-debugger.html

我仍在 Windows 上工作，我想查看 ELF 文件。有什么工具吗？我正在谷歌搜索，但直到现在都找不到。

我想写一个小函数的跟踪器。我使用 ptrace。

当我看到一条 CALL 指令时，我想显示与地址调用等效的函数名称。

我的跟踪器使用具有绝对地址的符号（符号在主二进制文件中定义）。但是我不知道如何才能获得共享库函数在虚拟内存中的绝对地址。例如，检测对 libc 函数的调用。

我注意到共享库中函数的地址是相对于文件的。

下面的等式是好的吗？

如何从共享库中获取符号的绝对地址？

我想写一个小函数的跟踪器。我使用 ptrace。我在 ubuntu x86_64 上。我想找到共享库函数的地址（如printf）。

但是我对全局偏移表有一些问题和一些疑问。我有以下代码：

readMemory在被跟踪进程的内存上读取的函数。

当我尝试阅读时linkList->l_ld，它似乎没有指向动态部分。

我不确定我的代码是否正确。当我使用readelf时，GOT 部分的地址与我找到的程序相同。

我必须只读取 GOT 部分的第一个偏移量还是更多？GOT 入口点仅包含指向struct link_map?

谢谢你。