Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support searching for kernel modules without modules.dep.bin #369

Open
pcc opened this issue Nov 21, 2023 · 0 comments
Open

Support searching for kernel modules without modules.dep.bin #369

pcc opened this issue Nov 21, 2023 · 0 comments

Comments

@pcc
Copy link
Contributor

pcc commented Nov 21, 2023

We currently search for kernel modules by reading the depmod modules.dep.bin file. However, not all Linux-based platforms use depmod, at least not in such a way that would be compatible with drgn as implemented. For example, in Android it is common for kernel modules to be stored in a flat directory on the build host (example) and then copied by the build system into various flashable images where they can be loaded by the target. While kernel module loading on Android does use depmod, it only generates modules.dep and not modules.dep.bin, and furthermore the modules are split between multiple images, including some stored exclusively in an initramfs on the target, which would make it difficult for drgn to access them if it were running on the target. So for these types of debugging scenarios I would expect that the easiest way for things to work would be that remote debugging is used on the build host, drgn is supplied with the path to the kernel modules directory on said host and it would be responsible for locating the module without the help of the modules.dep.bin file.

If the depmod-based kernel module search code were replaced with a recursive directory search, that seems like it would work in both existing use cases as well as these types of non-depmod use cases. This could have some impact on startup time, but on my M1 time find /lib/modules/(uname -r) -name '*.ko.zst' -false spends about 5ms in the kernel, which seems fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant