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
--
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
