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