问题标签 [fpic]

我正在构建一个在裸机上具有可重定位代码的项目。它是一个 Cortex M3 嵌入式应用程序。我没有动态链接器，并且在我的启动代码中实现了所有重定位。

大多数情况下它正在工作，但我的本地静态变量似乎定位不正确。它们的地址被我的可执行文件在内存中的偏移量所抵消——即我编译我的代码，就好像它是在内存位置 0 加载但我实际上将它加载到位于 0x8000 的内存中一样。静态局部变量的内存地址偏移量为 0x8000，这是不好的。

我的全局变量由 GOT 正确定位，但静态局部变量根本不在 GOT 中（至少在我运行时它们没有出现readelf -r）。我正在编译我的代码，并且-fpic链接器已经指定了。我认为我必须缺少一个编译和/或链接选项来指示将 GOT 用于静态局部变量或指示它对它们使用绝对寻址。 -fpic-piegcc

似乎当前代码将 PC 添加到静态局部变量的位置。

我已阅读GCC 的代码生成约定选项，但无法理解“生成与位置无关的代码 (PIC)”的作用。请举一个例子来解释我是什么意思。

我有一个项目，其中有一个静态库libhelper.a和另一个带有我的实际共享对象库的libtestlib.so. 我的目标是链接libhelper.a到libtestlib.so. 这在 Linux/BSD 上可行吗？当我尝试并创建一个测试程序时，出现以下错误：

./prog1:/usr/local/lib/libtestlib.so.1.0: 未定义符号''

我的猜测是，这是因为 libhelper.a 没有使用-fPICwhile libtestlib.sowas 编译。构建使用也依赖于静态库的共享库的程序的正确方法是什么？

谢谢！

据说位置无关代码只使用相对位置而不是绝对位置，这分别在c和汇编中是如何实现的？

举char test[] = "string";个例子，如何通过相对地址来引用呢？

有什么方法可以检查目标文件（.o 文件）是否启用了 PIC？

我正在尝试在 linux 机器上交叉编译 ImageMagick。工具链自带的 libstdc++.a 不是用 fPIC 编译的。我想改用so文件。但是 libtool 不断链接 libstdc++.a （作为整个档案），我得到重定位错误。我在其他图书馆也看到了同样的问题。有任何想法吗？

为什么 OSX 10.5 上的 GCC 默认开启 -fPIC 选项？毕竟，它不会生成更大更慢的代码吗？

我最近收到一个：

...重新定位 R_X86_64_32 反对“本地符号”在制作共享对象时不能使用；使用 -fPIC 重新编译

尝试将程序编译为共享库时出错。

现在解决这个问题并不太难（使用 -fPIC 重新编译所有依赖项），但经过一些研究发现这个问题只存在于 x86-64 平台上。在 32 位上，任何位置相关的代码仍然可以由动态加载器重新定位。

我能找到的最佳答案是：

x86 支持 .text 重定位（当您有位置相关代码时会发生这种情况）。这种支持是有代价的，即包含这种重定位的每个页面基本上都变得不共享，即使它位于共享库中，从而破坏了共享库的概念。因此我们决定在 amd64 上禁止这个（如果值需要超过 32 位，它会产生问题，因为所有 .text 重定位都只有大小“word32”）

但我觉得这还不够。如果重定位破坏了共享库的概念，为什么可以在 32 位平台上完成呢？此外，如果需要对 ELF 格式进行更改以支持 64 位，那么为什么不增加所有字段的大小以适应？

这可能是一个小问题，但它的动机是：a) 所讨论的代码是科学代码，不必受到性能影响会很好，b) 在第一名！

[编辑：'答案'

@awoodlands答案可能是最好的“字面答案”，@servn添加了一些很好的信息。

在搜索以查找有关不同类型重定位的更多信息时，我发现了这个并最终找到了x86_64 ABI 参考（参见第 68 页）]

我制作了一段代码，它包含在一个动态库 ( lib.c) 和一个主可执行文件 ( main.c) 中。在这两个文件中，我定义了一个名为： 的全局变量int global。不是很聪明，但这不是问题。

当我编译动态库时，该-fPIC选项似乎是强制性的：

否则我得到：

当我编译可执行文件时，它不是。

两者都有效，但有不同的行为我无法解释，你可以吗？：

使用 -fPIC，main.c 中的 global 和 lib.c 中的 global 是相同的变量：

如果没有 -fPIC，lib.c 中的全局与 main.c 中的全局无关：

这是来源：

库文件

主程序

gcc --version: gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2

uname -a: Linux xxx 2.6.38-11-generic #48-Ubuntu SMP Fri Jul 29 19:02:55 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

编辑：在 SUN/sparc 和 x86/Linux 架构下测试的代码具有相同类型的意外共享全局变量（使用 -fPIC）。

我正在尝试在 Fedora 中安装带有 -fPIC 支持的 GHC。我已经抓住了一个源代码压缩包，因为它似乎没有二进制文件有这个。

在 Build.mk 中，我将快速构建类型更改为

不幸的是，在编译时我仍然得到 ld 错误

所以似乎 GHC-prim 仍然没有使用 -FPIC 编译我还告诉 cabal 使用 -fPIC 构建任何包并共享。

有人有想法么？

编辑：感谢 dcouts 我已经能够取得一些进展。但是现在我正处于我认为 libffi 没有使用 -fPIC 编译的地步。我已经为它编辑了makefile(.in)，但到目前为止，还没有运气。

新命令是：

其中 dllmain.c 和 Hs2lib.hs 均已使用 -fPIC 编译。我得到的错误是：

collect2: ld 返回 1 个退出状态