On 2023/02/16 16:55, HAGIO KAZUHITO(萩尾 一仁) wrote: I've been looking into this, but it seems like we have to rewrite a very wide range of code related to modules and symbols, which assumes that each module's memory region is basically only one block. Probably the kernel patch will get merged into the mainline at v6.4. crash may take some time to support. Until finished, "crash --no_module" option can be used for linux-next without module functionality. $ crash --no_modules vmlinux vmcore ... WARNING: no kernel module access crash> Lianbo, my current working tree is here: https://github.com/k-hagio/crash/tree/6.4-module.wip1 but now it can just startup and run "mod" command. Other commands can cause a segmentation fault. crash> mod MODULE NAME BASE SIZE OBJECT FILE ffffffffc041f9c0 dm_mod ffffffffc0408000 217088 (not loaded) [CONFIG_KALLSYMS] ffffffffc0443100 pinctrl_sunrisepoint ffffffffc0441000 28672 (not loaded) [CONFIG_KALLSYMS] ffffffffc04e8340 sg ffffffffc044d000 53248 (not loaded) [CONFIG_KALLSYMS] ... Thanks, Kazu

On 2023/03/31 15:28, lijiang wrote: Thank you for working on the bugs. Ah yes, it's clear, because the current patch still does not support other commands and most of symbol functions fail. I'm working on making it support them one by one. so it's just to share the current status with you. (what a severe change for crash...) Thanks, Kazu

Hi, On 2023/03/31 16:13, lijiang wrote: Here is the current work branch, rebased on 8.0.3: https://github.com/k-hagio/crash/tree/6.4-module.wip1 Probably most of module and symbol functions will work, though maybe there might be lack of fixes for some functions and there might be my misunderstanding of crash code. (There are also some functions not fixed because crash does not use them for the recent kernels.) Please let me know if there are any bugs and comments on the design, coding style and etc. * The current patchset is a draft and kind of POC, fixes are piled up and no code and performance optimization. I will rearrange them later. (sorry no time to do it) * Currently enum mod_mem_type is backported from the kernel as it is, because I'm not sure whether it's likely to change soon. * The new module memory areas are scattered, and managed by the following struct load_module members. struct load_module { ... /* For 6.4 module_memory */ struct module_memory mem[MOD_MEM_NUM_TYPES]; struct syment **symtable; struct syment **symend; struct syment *ext_symtable[MOD_MEM_NUM_TYPES]; struct syment *ext_symend[MOD_MEM_NUM_TYPES]; struct syment *load_symtable[MOD_MEM_NUM_TYPES]; struct syment *load_symend[MOD_MEM_NUM_TYPES]; int address_order[MOD_MEM_NUM_TYPES]; int nr_mems; }; * "sym -M" output is ordered by module text start address on a per-module basis for now. (how can I say...) So if you get all of module symbols in address order, need to sort them. But modules will be mixed. crash> sym -M | grep MODULE # displayed per module ... ffffffffc046f000 MODULE TEXT START: dm_mirror ffffffffc0472000 MODULE TEXT END: dm_mirror ffffffffc0473000 MODULE DATA START: dm_mirror ffffffffc0475000 MODULE DATA END: dm_mirror ffffffffc0476000 MODULE RODATA START: dm_mirror ffffffffc0478000 MODULE RODATA END: dm_mirror ffffffffc044b000 MODULE RO_AFTER_INIT START: libata # lower than the previous ffffffffc044c000 MODULE RO_AFTER_INIT END: libata ffffffffc0479000 MODULE TEXT START: libata ffffffffc049d000 MODULE TEXT END: libata ffffffffc049e000 MODULE DATA START: libata ffffffffc04c8000 MODULE DATA END: libata ... crash> sym -M | grep MODULE | sort # displayed in address order ... ffffffffc0468000 MODULE RODATA START: dm_region_hash ffffffffc046a000 MODULE RODATA END: dm_region_hash ffffffffc046b000 MODULE RODATA START: t10_pi ffffffffc046c000 MODULE RODATA END: t10_pi ffffffffc046d000 MODULE TEXT START: ghash_clmulni_intel ffffffffc046e000 MODULE TEXT END: ghash_clmulni_intel ffffffffc046f000 MODULE TEXT START: dm_mirror ffffffffc0472000 MODULE TEXT END: dm_mirror ... And I will be on holidays next week, will be back the week after next. Thanks, Kazu

On 2023/05/10 16:38, lijiang wrote: No problem. Agree. I thought they were too rough to post, but will post them after tweaking a bit. Thanks, Kazu