Hi Kazu,
On Thu, Nov 16, 2023 at 1:30 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab@xxxxxxx> wrote:
>
> 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.
Thanks for testing the memory usage, agreed.
>
> 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?
>
I drafted a new patch to deal with the faulty check, please check out
the v2: [PATCH v2] symbols: expand all kernel module symtable if not
all expanded previously.
Thanks,
Tao Liu
> Thanks,
> Kazu
--
Crash-utility mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxxxxxx
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Contribution Guidelines: https://github.com/crash-utility/crash/wiki
