Re: [Crash-utility] Fix in bt for ARM64
----- Original Message -----
Hi Dave
I found an ARM64 problem for bt when a function belongs to a module.
Printout before fix given below:
#16 [ffffffc0be96f8d0] __this_module at ffffffbffc15a2f8 [wlan]
#17 [ffffffc0be96f9b0] __this_module at ffffffbffc161b18 [wlan]
#18 [ffffffc0be96f9c0] __this_module at ffffffbffc16033c [wlan]
#19 [ffffffc0be96fa10] __this_module at ffffffbffc1630f8 [wlan]
#20 [ffffffc0be96fab0] __this_module at ffffffbffc156ff8 [wlan]
#21 [ffffffc0be96faf0] __this_module at ffffffbffc15aa58 [wlan]
#22 [ffffffc0be96fb20] __this_module at ffffffbffc15bfc8 [wlan]
#23 [ffffffc0be96fb60] __this_module at ffffffbffc115fac [wlan]
#24 [ffffffc0be96fb90] tasklet_action at ffffffc000223738
#25 [ffffffc0be96fbb0] __do_softirq at ffffffc000222e94
Printout after fix:
#16 [ffffffc0be96f8d0] dhd_bus_rx_frame at ffffffbffc15a2f8 [wlan]
#17 [ffffffc0be96f9b0] dhd_update_flow_prio_map at ffffffbffc161b18 [wlan]
#18 [ffffffc0be96f9c0] dhd_update_flow_prio_map at ffffffbffc16033c [wlan]
#19 [ffffffc0be96fa10] dhd_prot_process_ctrlbuf at ffffffbffc1630f8 [wlan]
#20 [ffffffc0be96fab0] dhd_bus_ringbell at ffffffbffc156ff8 [wlan]
#21 [ffffffc0be96faf0] dhd_bus_console_in at ffffffbffc15aa58 [wlan]
#22 [ffffffc0be96fb20] dhd_bus_dpc at ffffffbffc15bfc8 [wlan]
#23 [ffffffc0be96fb60] dhd_sched_dpc at ffffffbffc115fac [wlan]
#24 [ffffffc0be96fb90] tasklet_action at ffffffc000223738
#25 [ffffffc0be96fbb0] __do_softirq at ffffffc000222e94
From arm64.c:
static int
arm64_print_stackframe_entry(struct bt_info *bt, int level, struct
arm64_stackframe *frame)
{
char *name, *name_plus_offset;
ulong symbol_offset;
struct syment *sp;
struct load_module *lm;
char buf[BUFSIZE];
name = closest_symbol(frame->pc);
name_plus_offset = NULL;
if (bt->flags & BT_SYMBOL_OFFSET) {
/*ADDED*/
if (module_symbol(frame->pc, NULL, &lm, NULL, 0))
sp = value_search_module(frame->pc, &symbol_offset);
else
/*END ADDED*/
sp = value_search(frame->pc, &symbol_offset);
Hi Jan,
I don't dispute that this is something to be fixed, but at the same
time I don't quite understand (1) why it's happening, and (2) how your
fix addresses it?
The value_search() function does this if it's a module address:
struct syment *
value_search(ulong value, ulong *offset)
{
...
if (IS_VMALLOC_ADDR(value))
goto check_modules;
...
check_modules:
sp = value_search_module(value, offset);
return sp;
}
And even if IS_VMALLOC_ADDR() above fails, it should just fail to find it in
the base kernel symbols, and fall through to the value_search_module() call.
Does something different happen in your case?
I also note that in all cases "__this_module" is in the "(d)" section
of each
module, and typically is the last/highest symbol value of the module. So I'm
confused as to how it's getting picked up as the closest value to all of
the different text addresses in the wlan module?
What does "sym -m wlan" look like?
Thanks,
Dave
You probably also want to prevent calling module_symbol a second time later
in the function.
Jan
Jan Karlsson
Senior Software Engineer
System Assurance
Sony Mobile Communications
Tel: +46 703 062 174
jan.karlsson(a)sonymobile.com
sonymobile.com
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility