为什么链接器要修改--defsym“绝对地址”

目标：一个使用可执行文件中的函数（不导出符号）的共享库。

Means: gcc -Wl,--defsym,function=0x432238

手册页指出：

"--defsym symbol=expression" Create a global symbol in the output
file, containing the absolute address given by expression.

令我沮丧的是，dlopen()正在添加0x7ffff676f000，共享库的基地址（这是 64 位代码）到导出的“绝对符号地址”：

        executable        shared library
        ---------- linker --------------
symbol: 0x432238   =====> 0x7ffff6ba1238

objdump 显示正确的符号地址（0x432238）在库中，但一旦加载dlopen()，符号有地址0x7ffff6ba1238.

如果加载后，我手动将库符号修补到正确的地址，则一切正常（否则，库 SEGFAULT）。

• 为什么要修改“绝对地址”呢？
• 如何避免呢？

Update:

我对下面回复的技术相关性提出质疑，甚至更质疑其“更新”：

使用 --defsym 在 PIC 库/可执行文件中定义重定位符号是没有意义的（除了污染二进制文件而没有任何可用功能之外，它没有任何用途）。

因此，在 PIC 共享库或 PIC 可执行文件中 --defsym 的唯一相关用途应该是定义 (未搬迁)“绝对地址”。

顺便说一句，如果您费心阅读手册页，这就是 --defsym 的官方目的：

“在输出文件中创建一个全局符号，包含absolute address由表达式给出。”

充其量，这是一个 Linux 链接器缺陷，修复起来很简单。对于那些迫不及待地等待否认者意识到（并修复）他们的错误的人来说，解决方案是在有缺陷的链接器加载二进制映像后修补重定位表。

然后，--defsym 在 PIC 库/可执行文件中变得有用，在我看来这是一个可喜的进步。

你似乎从根本上误解了什么--defsym does.

--defsym=symbol=expression
   Create a global symbol in the *output* file, ...

也就是说，您正在创建新符号在图书馆你正在建造的。因此，该符号（自然地）随库一起重新定位。

我猜你想要这样的东西：

// code in library
int fn()
{
    // exe_fn not exported from the executable, but we know where it is.
    int (*exe_fn)(void) = (int (*)(void)) 0x432238;
    return (*exe_fn)();
}

如果你不想硬编码0x432238到库中，而不是在构建时在命令行上传递值，只需使用-DEXE_FN=0x432238为了实现这一点。

Update:

目标：使用可执行文件中的函数的共享库

那个目标can not通过您选择的方法来实现。你必须使用其他手段。

为什么要修改“绝对地址”呢？

事实并非如此。当您要求链接器定义时function在绝对地址处0x432238，它确实exactly那。你可以在objdump, nm and readelf -s output.

但因为符号已定义in共享库，所有参考到该符号的位置被重定位，即通过共享库加载地址进行调整（由动态加载器完成）。它使毫无意义让动态加载器做其他事情。

如何避免呢？

你不能。使用其他手段来实现你的目标。