如何获取库函数的内存位置？

Question

我正在使用 SPARC RTEMS C 编译器编译 C 程序。

使用 Xlinker -M 选项，我可以获得一个大的内存映射，其中有很多我不认识的东西。

我还尝试使用 RCC nm 实用程序，它返回一个稍微更可读的符号表。 我假设该实用程序给出的位置（例如 printf）是 printf 在内存中的位置，并且每个调用 printf 的程序在执行期间都会到达该位置。 这是一个有效的假设吗？

有没有办法获取所有库/系统功能的位置列表？ 另外，链接完成后，它是仅链接可执行文件调用的函数，还是链接库中的所有函数？ 考虑到我在符号表和内存映射中发现的东西的数量，在我看来是后者。 我可以让它只链接所需的功能吗？

感谢您的帮助。

Answer 1

如果要动态链接，请使用 dlopen/dlsym 来解析 UNIX .so 共享库入口点。

http://www.opengroup.org/onlinepubs/009695399/functions/dlsym。假设

您知道要调用的函数的名称以及它们位于哪个 .so 中。这相当简单。

void    *handle;
int     *iptr, (*fptr)(int);

/* open the needed object */
handle = dlopen("/usr/home/me/libfoo.so", RTLD_LOCAL | RTLD_LAZY);

/* find the address of function and data objects */
*(void **)(&fptr) = dlsym(handle, "my_function");
iptr = (int *)dlsym(handle, "my_object");

/* invoke function, passing value of integer as a parameter */
(*fptr)(*iptr);

如果您想获取所有动态符号的列表，那么 objdump -T file.so 是您最好的选择。 （如果您正在寻找静态绑定函数，则 objdump -t file.a ）。 objdump 是跨平台的，是 binutils 的一部分，因此在紧要关头，您可以将二进制文件复制到另一个系统，并在不同平台上使用 objdump 进行交互。

如果您希望动态链接达到最佳效果，您应该查看 ld.so.conf，它指定了 ld.so.cache 的搜索顺序（so.cache 正确；）。

Answer 2

大多数情况下，当使用动态库时，nm 实用程序将无法为您提供准确的答案。 如今的二进制文件使用所谓的可重定位地址。 这些地址在映射到进程的地址空间时会发生变化。

使用 Xlinker -M 选项，我可以获得一个大的内存映射，其中有很多我不认识的东西。

链接器映射通常包含所有符号——您的、标准库、运行时挂钩等。

有什么方法可以获取所有库/系统功能的位置列表吗？

标题是一个很好看的地方。

此外，链接完成后，它是仅链接可执行文件调用的函数，还是链接库中的所有函数？

链接并不一定意味着所有符号都将被解析（即给定地址）。 这取决于您创建的二进制文件的类型。

然而，一些编译器（例如 gcc）确实允许您是否创建不可重定位的二进制文件。 （对于 gcc，您可以查看 exp 文件、dlltool 等）查看相应的文档。

Answer 3

通过动态链接，
1. 您的可执行文件有一个特殊的位置用于所有外部调用（PLT 表）。
2.你的可执行文件有一个它所依赖的库列表

这两件事是独立的。 不可能说哪个外部函数位于哪个库中。

当程序执行外部函数调用时，实际上会调用 PLT 表中的一个条目，该条目会跳转到动态加载程序。 动态加载器查找调用了哪个函数（通过 PLT），查找其名称（通过可执行文件中的符号表）并在所有映射的库中查找该名称（所有给定的可执行文件都依赖）。 一旦找到名称，相应函数的地址就会写回PLT，这样下次调用就可以直接绕过动态链接器。

要回答您的问题，您应该执行与动态链接器相同的工作：获取依赖库的列表，并查找其中的所有名称。 这可以使用“nm”或“readelf”实用程序来完成。

至于静态链接，我认为 libXXX.a 中给定目标文件中的所有符号都会被链接。例如，静态库 libXXX.a 由目标文件 ao、bo 和 co 组成。如果您需要一个函数 foo()，它位于在 ao 中，然后 ao 将链接到您的应用程序 - 以及函数 foo() 和其中定义的所有其他数据。 这就是为什么 C 库函数被拆分为每个文件的原因。