如何获取使用 insmod 插入的内核模块的地址?

发布于 2024-11-16 04:38:29 字数 115 浏览 5 评论 0原文

我想知道内核模块的地址。实际上,从堆栈跟踪来看,崩溃是由内核模块触发的(系统启动后已插入)。有几个模块是我手动安装的。所以我需要检测其中哪个模块触发了崩溃。请让我知道如何获取使用 insmod 加载的每个模块的地址。

I would like to know the address of a kernel module. Actually, from stack trace it looks that the crash has been triggered from a kernel module (which have been insmoded after system boots up). There are several modules I insmod manually. So I need to detect which module among these is triggering the crash. Please let me know how to get the address of each modules loaded using insmod.

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

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

发布评论

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

评论(3

枯寂 2024-11-23 04:38:29

cat /proc/modules 应该为您提供加载内容的粗略指南。通过查看 /proc/kallsyms,您可能会获得更多关于内核崩溃的确切位置的线索。

cat /proc/modules should give you a rough guide to where things are loaded. You might get more of a clue about exactly where the kernel crash is by looking at /proc/kallsyms.

秋风の叶未落 2024-11-23 04:38:29

/sys/module//sections/ 包含模块所有部分的地址。由于大多数部分都以点 (.) 开头,因此在列出此目录内容时,不要忘记将 -a 传递给 ls

$ ls -a /sys/module/usbcore/sections/
.                      __ex_table                 __param
..                     .fixup                     .rodata
.altinstr_replacement  .gnu.linkonce.this_module  .rodata.str1.1
.altinstructions       .init.text                 .rodata.str1.8
.bss                   __kcrctab_gpl              .smp_locks
__bug_table            __ksymtab_gpl              .strtab
.data                  __ksymtab_strings          .symtab
.data..read_mostly     __mcount_loc               .text
.data.unlikely         .note.gnu.build-id         .text.unlikely
.exit.text             .parainstructions          __verbose

/sys/module/<MODULE_NAME>/sections/ contains addresses of all sections of your module. Since most section begin with a dot (.), don't forget to pass -a to ls when listing this directory content:

$ ls -a /sys/module/usbcore/sections/
.                      __ex_table                 __param
..                     .fixup                     .rodata
.altinstr_replacement  .gnu.linkonce.this_module  .rodata.str1.1
.altinstructions       .init.text                 .rodata.str1.8
.bss                   __kcrctab_gpl              .smp_locks
__bug_table            __ksymtab_gpl              .strtab
.data                  __ksymtab_strings          .symtab
.data..read_mostly     __mcount_loc               .text
.data.unlikely         .note.gnu.build-id         .text.unlikely
.exit.text             .parainstructions          __verbose
北方的韩爷 2024-11-23 04:38:29

pr_debug on dmesg

如果我们启用pr_debug,那么它会显示加载模块的基地址。

例如,如果模块在 init_module 处发生紧急情况并且您无法交互读取 /proc/modules,这可能会很有用。

启用 pr_debug 的最佳方法是使用 CONFIG_DYNAMIC_DEBUG=y 编译内核,如下所述:为什么是Linux 内核的 pr_debug 没有给出任何输出?

然后当你这样做时:

echo 8 > /proc/sys/kernel/printk
echo 'file kernel/module.c +p' > /sys/kernel/debug/dynamic_debug/control
insmod mymodule.ko

我们看到一行形式:

0xffffffffc0005000 .text        

其中包含基地址。

pr_debug on dmesg

If we enable pr_debug, then it shows the base address the module was loaded at.

This can be useful for example if the module panics at init_module and you can't read /proc/modules interactively.

The best way to enable pr_debug is to compile the kernel with CONFIG_DYNAMIC_DEBUG=y as explained at: Why is pr_debug of the Linux kernel not giving any output?

Then when you do:

echo 8 > /proc/sys/kernel/printk
echo 'file kernel/module.c +p' > /sys/kernel/debug/dynamic_debug/control
insmod mymodule.ko

we see a line of form:

0xffffffffc0005000 .text        

which contains the base address.

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