----- Original Message ----- > > > ----- Original Message ----- > > We are using ELFXX_sym->st_info directly as the 'type' of symbol, > > which is wrong, because st_info contains numeric value which needs > > to be mapped to appropriate type character. > > I'm confused here. If I dump each module symbol's st_info fields as they are > being read/initialized, they always contain the unsigned char ASCII value for > either 't', 'r', 'd', 'b' or 'w'. What do you mean that it needs to be mapped > to the appropriate type character? And for that matter, since your patch marks all module symbols as type '?', commands like "dis" fail to recognize a module text address as such, and therefore fails to complete the command. For example, without the patch: crash> sym dm_put ffffffffa0000520 (t) dm_put [dm_mod] crash> dis dm_put 0xffffffffa0000520 <dm_put>: nopl 0x0(%rax,%rax,1) [FTRACE NOP] 0xffffffffa0000525 <dm_put+5>: push %rbp 0xffffffffa0000526 <dm_put+6>: mov %rsp,%rbp 0xffffffffa0000529 <dm_put+9>: lock decl 0x180(%rdi) 0xffffffffa0000530 <dm_put+16>: pop %rbp 0xffffffffa0000531 <dm_put+17>: retq crash> With your patch applied: crash> sym dm_put ffffffffa0000520 (?) dm_put [dm_mod] crash> dis dm_put 0xffffffffa0000520 <dm_put>: nopl 0x0(%rax,%rax,1) [FTRACE NOP] crash> Dave > > Dave > > > > Sections headers are > > also required to correctly map st_info to symbol type which are > > missing here (lm->mod_section_data is NULL). Use '?' for now. This > > fixes 'trace' extension which segfaults internally while parsing > > module kallsyms: > > > > Before patch: > > crash> trace show > > crash> > > > > After patch: > > crash> trace show > > cpus=4 > > <idle>-0 [002] 4350.912553: function: __hrtimer_get_next_event <-- > > hrtime > > <idle>-0 [002] 4350.912553: function: __hrtimer_next_event_base <-- > > __hrt > > > > Signed-off-by: Ravi Bangoria <ravi.bangoria@xxxxxxxxxxxxx> > > --- > > symbols.c | 14 ++++++++++++-- > > 1 file changed, 12 insertions(+), 2 deletions(-) > > > > diff --git a/symbols.c b/symbols.c > > index e73e735..4456cd3 100644 > > --- a/symbols.c > > +++ b/symbols.c > > @@ -2188,7 +2188,12 @@ Elf32_Sym_to_common(Elf32_Sym *e32, struct > > elf_common > > *ec) > > ec->st_name = (ulong)e32->st_name; > > ec->st_value = (ulong)e32->st_value; > > ec->st_shndx = (ulong)e32->st_shndx; > > - ec->st_info = e32->st_info; > > + /* > > + * Section headers are required to correctly map st_info > > + * to symbol type, which are missing here. Let's use '?' > > + * for all kernel module symbols type. > > + */ > > + ec->st_info = '?'; > > ec->st_size = (ulong)e32->st_size; > > } > > > > @@ -2198,7 +2203,12 @@ Elf64_Sym_to_common(Elf64_Sym *e64, struct > > elf_common > > *ec) > > ec->st_name = (ulong)e64->st_name; > > ec->st_value = (ulong)e64->st_value; > > ec->st_shndx = (ulong)e64->st_shndx; > > - ec->st_info = e64->st_info; > > + /* > > + * Section headers are required to correctly map st_info > > + * to symbol type, which are missing here. Let's use '?' > > + * for all kernel module symbols type. > > + */ > > + ec->st_info = '?'; > > ec->st_size = (ulong)e64->st_size; > > } > > > > -- > > 1.8.3.1 > > > > -- > > Crash-utility mailing list > > Crash-utility@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/crash-utility > > > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility > -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
