![Module.symvers 文件生成背后的逻辑是什么?](https://linux22.com/image/183432/Module.symvers%20%E6%96%87%E4%BB%B6%E7%94%9F%E6%88%90%E8%83%8C%E5%90%8E%E7%9A%84%E9%80%BB%E8%BE%91%E6%98%AF%E4%BB%80%E4%B9%88%EF%BC%9F.png)
据我了解模块.symvers文件提供导出的符号列表按模块加上许可证,这些文件可以根据 CRC 导出(可选)。其他模块可以依赖这些符号来实现其目的,并且如果我的模块依赖于某些符号,那么这肯定是合乎逻辑的模块X, 这模块X至少应该被建造,因为它定义我需要的符号。模块.symvers因此可以作为健全性检查机制,对吗?
我很难理解为什么有些符号清楚地不依赖于任何未导出的模块,例如我想使用debugfs_create_u32
函数。在我看来,应该存在的唯一依赖项是CONFIG_DEBUG_FS
,但是启用此选项仅导出声明的符号的一小部分#include <linux/debugfs.h>
。因此,每次我尝试编译模块时,都会收到有关未定义符号的 MODPOST 错误。我的解决方法是找到debugfs_create_u32
在代码中实际使用符号的随机模块并用它编译内核,该模块没有定义debugfs_create_u32
,我不使用该模块的功能,我实际上不需要它,感觉这是唯一有用的东西这个模块对我来说就是添加行模块.symvers文件,一切都开始神奇地工作。我在符号上遇到了类似的问题i8253_lock
,我不需要pcspkr
模块,我只想要i8253_lock
,但为了得到它,我需要pcspkr
出于某种原因进行编译。
我很确定我在这里遗漏了一些关键的东西,这就是为什么我如此困惑,因此我恳请解释如何理解上述情况,生成背后的逻辑是什么模块.symvers?
答案1
我不知道你是否仍在为这个问题苦苦挣扎,我知道现在有点晚了,但今晚我遇到了同样的问题。罪魁祸首是内核配置中的以下选项:
CONFIG_TRIM_UNUSED_KSYMS
https://cateee.net/lkddb/web-lkddb/TRIM_UNUSED_KSYMS.html
如果您激活了该选项,只需将其禁用即可。
希望能帮助到你。