[Crash-utility] Re: [PATCH] symbols: expand kernel modules symtable when loading by mod -s/-S

On 2023/11/15 18:16, Tao Liu wrote: >> a question, is "mod -S -r" a workaround for it? >> > Yes, it can work as expected with "mod -S -r", I didn't know "-r" > parameter can trigger such symble expansion. Thank you for the check. >> I'm thinking that, if the current gdb's auto expansion is not good for >> crash, maybe we can make the behavior of "mod -r" option default. The >> option adds "-readnow" to the add-symbol-file command and it looks same >> as your patch to me: >> >> $ vim gdb-10.2/gdb/symfile.c >> >> /* We now have at least a partial symbol table. Check to see if the >> user requested that all symbols be read on initial access via either >> the gdb startup command line or on a per symbol file basis. Expand >> all partial symbol tables for this objfile if so. */ >> >> if ((flags & OBJF_READNOW)) >> { >> if (should_print) >> printf_filtered (_("Expanding full symbols from %ps...\n"), >> styled_string (file_name_style.style (), name)); >> >> if (objfile->sf) >> objfile->sf->qf->expand_all_symtabs (objfile); >> } >> > Agreed, they do the same work. Thanks again for your suggestions. Do > you want me to draft the "making mod -r option default" patch now or > later? This is an idea, I think it's better to evaluate more whether we can make it default. Any trade-off? For example, the -r option uses much memory.. after startup: root 327522 53.3 3.9 1814472 545756 pts/2 Sl+ 14:05 0:03 crash after "mod -S": root 327522 24.9 4.1 1851184 585052 pts/2 Sl+ 14:05 0:04 crash after "mod -D": root 327522 19.6 4.1 1843360 578408 pts/2 Sl+ 14:05 0:04 crash after "mod -S -r": root 327522 23.3 11.6 2884148 1621016 pts/2 Sl+ 14:05 0:11 crash This seems too much and a bit dangerous to make it default.. So I think it's better to try to search for another way with the on-demand expansion if possible.

BTW, according to your commit log, > !objfile_has_full_symbols(objfile) check will fail, so it cannot display > the proper code line number data. this check seems a fault, is there no way to improve this?

Thanks, Kazu