You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 generatesmodules.dep
and notmodules.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 themodules.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.The text was updated successfully, but these errors were encountered: