如果共享对象与原始对象相比有额外的符号，为什么它会失败
我有一个剥离的 ld.so 我想用未剥离的版本替换（以便 valgrind 工作）。我已经确保我有相同版本的 glib 和交叉编译器。
我已经编译了共享对象，在其上调用“文件”表明它已正确编译（与原始文件的唯一区别是“未剥离”并且大约大 15%）。不幸的是，它会在启动时导致内核恐慌（无法初始化）。剥离新编译的 .so，重新读取它并与原始版本进行比较，表明新版本的 .so 中有额外的符号。所有旧符号仍然存在，所以我不明白为什么内核会因这些额外符号而发生恐慌。
我希望额外的符号对内核启动没有影响，因为它们永远不应该被调用，那么为什么我会出现内核恐慌呢？
注意：需要明确的是 - 我仍然需要调查为什么有额外的符号，但我的问题是为什么这些未使用的符号会导致问题。
I have a stripped ld.so that I want to replace with the unstripped version (so that valgrind works). I have ensured that I have the same version of glib and the cross compiler.
I have compiled the shared object, calling 'file' on it shows that it is compiled correctly (the only difference with the original being the 'unstripped' and being about 15% bigger). Unfortunately, it then causes a kernel panic (unable to init) on start up. Stripping the newly compiled .so, readelf-ing it and diff-ing it with the original, shows that there were extra symbols in the new version of the .so . All of the old symbols were still present, so what I don't understand is why the kernel panics with those extra symbols there.
I would expect the extra symbols to have no affect on the kernel start up, as they should never be called, so why do I get a kernel panic?
NB: To be clear - I will still need to investigate why there are extra symbols, but my question is about why these unused symbols cause problems.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
内核（假设是 Linux）不以任何方式、形状或形式依赖或使用 ld.so。它发生恐慌的原因很可能是它无法执行任何用户级程序（例如
/bin/init和/bin/sh），而这些程序确实使用ld.so。至于为什么你的
init不喜欢你的新ld.so，很难说。一个常见的错误是尝试用/usr/lib/debug/ld-XYso的内容替换ld.so。虽然该文件看起来与原始/lib/ld-XYso没有太大区别，但实际上它非常不同，并且不能用来替换原始文件，仅用于调试原始版本（/usr/lib/debug/ld-XYso通常仅包含调试部分，但/lib/ld-XYso的代码和数据部分都不包含>，因此尝试运行它通常会立即导致SIGSEGV）。也许您可以设置一个
chroot，模仿您的嵌入式环境，并在其中运行/bin/ls？这将产生的错误（或核心转储）可能会告诉您ld.so出了什么问题。The kernel (assuming Linux) doesn't depend on or use
ld.soin any way, shape or form. The reason it panics is most likely that it can't exec any of the user-level programs (such as/bin/initand/bin/sh), which do useld.so.As to why your
initdoesn't like your newld.so, it's hard to tell. One common mistake is to try to replaceld.sowith the contents of/usr/lib/debug/ld-X.Y.so. While that file looks like it's not much different from the original/lib/ld-X.Y.so, it is in fact very different, and can't be used to replace the original, only to debug the original (/usr/lib/debug/ld-X.Y.sousually contains only debug sections, but none of code and data sections of/lib/ld-X.Y.so, and so attempts to run it usually cause immediateSIGSEGV).Perhaps you can set up a
chroot, mimicking your embedded environment, and run/bin/lsin it? The error (or a core dump) this will produce will likely tell you what's wrong with yourld.so.