问题标签 [relocation]

我目前无法理解 PE Base Relocations 是如何建立的。

我知道可以有不止一个搬迁，我也了解为什么以及如何做到这一点，但我只是不以编程方式理解它：

以下哪项是正确的（WinNT.h 中的 IMAGE_BASE_RELOCATION）？

或者

还是两者都不正确？我必须如何以编程方式遍历所有基本重定位？

目前我有这段代码，在某处似乎不正确：

是否可以将已链接的 elf 文件重新定位到另一个地址并更新内部引用？

例如，有一个静态链接的 elf 文件链接在 0x50000，我怎样才能将它移动到 0x1000000 并更新指针和地址？

嘿嘿，

我目前正在开发一个 bukkit 插件，我想使用番石榴。Bukkit 仍然使用 Guava 11.0，但我想使用 14.0。所以我试图在我的主模块中重新定位番石榴。这非常有效。同一级别的另一个模块也使用番石榴，它需要“相同的”番石榴。所以主要项目中也使用了番石榴。当然，导入发生了变化，主项目和其他模块不兼容。

项目结构：

家长：

• 主模块：使用重定位版本的番石榴（14.0）#
• 另一个模块：使用 guava 14.0 但未重新定位 -> 与主模块不兼容

我已经尝试将番石榴重新定位到另一个模块中的相同路径，但没有任何反应。

也许有人知道如何解决这个问题。我只需要一种在我的其他模块中使用我重新定位的番石榴的方法：/

相关文章：跨所有模块的 Maven 阴影重定位？

如果我在底部编译示例代码

我得到一个带有一些重定位的共享库（readelf lib.so -r）：

直到现在我相信，链接器会解析所有静态重定位并在必要时生成动态重定位（由加载器处理）。为什么链接器输出中会留下静态重定位？ 该文档说， R_ARM_ABS32 是静态重定位，并且：

静态重定位由静态链接器处理；它们通常要么完全解析，要么用于生成动态重定位，以供后链接步骤或动态加载器处理。静态链接完成后，格式良好的图像将没有静态重定位，因此后链接器或动态加载器通常只需要处理动态重定位。

顺便说一句，这也可以使用 i386-elf-gcc 重现，那里使用的静态重定位是 R_386_32。

谁能告诉我，为什么并告诉我，哪些重定位应该在装载机中真正处理？提前致谢！

示例代码：

在创建最终图像之前解决目标文件中的重定位时，链接器究竟采取了哪些步骤？更具体地说，链接器如何处理已经存储在重定位站点的值？它是否总是将其添加到最终的 VA/RVA 中，还是有时会被忽略（例如某些重定位类型）？

我在MS PE/COFF Specfication中找不到明确的解释，经过一段时间的谷歌搜索和实验，我能找到的只是：

1. 在 MS COFF 规范的第 5.6.2 章“基本重定位类型”中，据说“基本重定位将所有 32 位差异应用于偏移处的 32 位字段”，我猜这意味着重定位应该采取考虑到任何地址已经存储在指定的偏移量。但是，第 5.6 章（.reloc 部分）仅与图像文件相关，与目标文件无关。
2. 在打印重定位表时，dumpbin 实用程序添加了一个名为“Applied To”的列，它似乎总是（无论重定位类型）包含存储在重定位站点的值。
3. DJGPP COFF 规范中的重定位指令一章明确指出，当前存储在该位置的值应添加到重定位表条目所指向的符号地址。

您能否指出任何（相关）文档来解释链接器如何处理重定位？

据我所知，x86 汇编代码在很大程度上受到有限数量的寄存器的限制。

当我了解到在 Linux 上创建 .so 文件时，必须为 gcc 指定 -fPIC 命令行参数才能创建与位置无关的代码，我一开始简直不敢相信。

据我所知，elf 文件格式支持重定位，就像 - 在我看来要好得多 - Windows DLL 系统的工作原理：在 Windows 上，如果有必要，链接器会重定位 DLL 中的所有偏移量。

我认为加载 SO 文件或 DLL 文件所需的时间，以及用于保存不同重定位的 .so 文件的内存量并不像始终缺少整个寄存器那样糟糕，这指向GOT 并拥有所有这些间接跳跃。

我也完全不关心 ALSR 等，因为我只关心库中的代码要尽可能地优化。

1) 为什么 Linux 不支持像 Windows 这样应该产生更高性能代码的更多动态库加载？

到目前为止，我还没有找到真正的解释。像这样的事情，重新定位代码会非常糟糕和缓慢（当然，对于在台式机上加载文字处理器，加载速度有多快很重要，我完全接受这一点。但是对于计算密集型服务器进程（不处理来自互联网的恶意数据），我想拥有我能得到的所有性能和寄存器！

2) 我可以在 Linux 上创建 NOT -fPIC 编译的 SO 文件吗？我可以离开 -fPIC 吗？是否有任何关于该主题的操作指南、手册或项目，并且可以不浪费整个寄存器并仍然动态加载库？

如果我在编译 .so 文件时只删除 -fPIC 会发生什么？

我的机器（Ubuntu 12.04）上安装了MPICH 3.0.4 。我正在尝试安装一个名为Qthreads的库，我之前曾使用并成功安装过该库（安装了 MPICH2 包除外）。配置工作正常：

./configure --prefix=/usr/local/qthreads --enable-multinode --with-multinode-runtime=mpi --with-portals4=/usr/local/portals4 --with-hwloc=/usr/local/hwloc：

当我尝试运行make时，我收到以下错误：

我环顾四周，似乎明显（也是唯一可能的）解决方案是按照编译器所说的：重新编译-fPIC. 但是，我很犹豫是否要浏览和编辑 Qthreads 的任何 Makefile，因为它们又长又复杂。有没有一种简单的方法来重新编译-fPIC？

请指教。我很感激任何意见。

Using Ulrich Drepper's relinfo.pl script, one can easily count the number of relocations of a DSO, but it doesn't work on .o files.

Say I have a large shared library and I'm not happy about the number of its relocations. is there a way to find out where they come from (symbol, or at least .o), to check whether they're of the easily fixable type (e.g.: const char * str = "Hello World";' -> const char str[] = "Hello World";)?

我们正在 SELinux 环境中测试我们的应用程序。现在，我们收到以下错误：

据我从搜索中了解到，这与.text共享库中的部分中的重定位有关。据我所知，我们已经在使用-fPIC我们所有的共享库。尽管可能有一些静态库也链接到这些共享库中。

如何找出导致此错误弹出的重定位/符号？我应该在共享库中查找nm或输出什么？objdump -rR

还是我在寻找错误的信息，而问题出在共享库中产生的重定位之外的其他地方？

我是这个社区的新手，因为我以前从未创建过帐户并提出过问题，但我一直使用这个网站来解决我的编程难题。所以谢谢！但是，这一次，我找不到另一个符合我确切需求的问题。如果这是重复，我很抱歉。

我使用的是 Ubuntu 12.04 的衍生版本 Elementary OS 0.2 (Luna)。我正在使用 avr-gcc 库为 ATmega32u4 微处理器编译程序。我在开发这个程序时已经编译了好几次，但直到现在我还没有收到这个错误。我把它贴在下面。

简而言之，我不知道这是指什么。我的程序包含大量文件，所以我不能在这里准确地发布整个内容；相反，我会对以下问题的一般性答案感兴趣：

1. 什么是“重定位截断以适应”错误？我读过它与访问太远的内存有关，但是在我的 C 程序中实际上是如何发生的呢？
2. 什么是 R_AVR_13_PCREL？它似乎是 avr-gcc 库所固有的；我的程序的哪个方面可能会引用这样的变量？
3. 我包含的唯一通用 C 头文件是 math.h；其他文件是我自己的。我知道 math.h 有一个时髦的标志，应该放在 Makefile 中；我相信它是-lm。但我试过这个无济于事。

非常感谢大家。我感谢这个社区的帮助。