Hi, Kazu
Sorry for the late reply.On Fri, Apr 28, 2023 at 12:32 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx> wrote:
Hi,
On 2023/03/31 16:13, lijiang wrote:
> On Fri, Mar 31, 2023 at 2:51 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab@xxxxxxx>
> wrote:
>
>> On 2023/03/31 15:28, lijiang wrote:
>> 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.
Here is the current work branch, rebased on 8.0.3:
https://github.com/k-hagio/crash/tree/6.4-module.wip1
Nice work.
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.
I will have a look in the following weeks. And give the feedback ASAP.
* 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)
No worries.
BTW: I would suggest posting these patches upstream first, because it may be more convenient to comment on them.
Thanks.
Lianbo
* 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
-- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/crash-utility Contribution Guidelines: https://github.com/crash-utility/crash/wiki
