ELF 中的库符号和用户符号

发布于 2024-12-09 00:53:58 字数 136 浏览 0 评论 0原文

我的问题与 ELF 中的符号有关。正如我们所知,ELF 的符号表保存了定位和重新定位程序的符号定义和引用所需的信息。

我的问题是,我们可以区分 b/wa 库符号和用户定义符号(如果两者都是全局的)吗?考虑没有源代码可用且只有 ELF 的场景。

My questions is related to symbols in an ELF. As we know an ELF's Symbol table holds information needed to locate and relocate a program’s symbolic definitions and references.

My question is that can we differentiate b/w a library symbol and user defined symbol (if both are global)? consider the scenario in which no source code is available and you have only ELF.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

云裳 2024-12-16 00:53:58

静态库只是未链接的目标文件 (.o) 的存档(带有索引以加快链接器搜索其中的符号)。当您链接此类库时,链接器会获取每个未解析的符号并尝试在那里找到它。如果找到,则提取相应的对象并将其添加到集合中进行链接。所以不,你无法判断符号是否来自静态库

如果您有另一个与可执行文件所链接的对象足够接近的库实例,您可以查看它定义的符号,然后假设所有这些符号以及它们依赖的任何符号都来自该库。

当然可以告诉共享库中定义的符号,因为它仍然是不同的文件。

但还有一点:提供没有与 libc 静态链接的源的 Linux 二进制文件很可能非法。也就是说,如果该 libc 是 GNU Libc,那么它绝对是非法的,因为它是根据 LGPL 条款分发的,并且 LGPL 要求提供(根据请求)所有派生代码的源代码,动态链接到它的代码除外嗯>。如果它使用不同的 libc,例如 sourceware newlib 或 bionic libc (Android)(我找不到其他)。然而我不确定这样的代码在基于 GNU libc 的系统中运行得如何。

A static library is just an archive of unlinked object files (.o) (with index to speed up linker searching for symbols in it). When you link against such library, the linker takes each unresolved symbol and tries to find it there. If it finds it, it extracts corresponding object and adds it to the collection to link. So no, you can't tell whether symbol comes from static library.

If you have another instance of the library that is sufficiently close to what the executable was linked against, you could look which symbols it defines and than assume that all those symbols, plus any symbols those depend on, come from the library.

It is of course possible to tell symbols defined in shared library, because that remains different file.

But there is another point: It is most likely illegal to provide a Linux binary without sources statically linked against libc. That is, it is definitely illegal if that libc is the GNU Libc, because that is distributed under the terms of LGPL and LGPL requires providing (on request) sources of all derived code excepting code that is linked to it dynamically. If it uses different libc like sourceware newlib or bionic libc (Android) (I can't find any other). I am not however sure how well such code would work in a GNU libc-based system.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文