Re: [PATCH v3 7/8] gdb/aarch64: Detect vector length changes when debugging remotely

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi <simark@simark.ca> writes:

>> I guess the point I'm driving towards is that maybe instead of a new
>> gdbarch method we should add something like gdbarch_from_tdesc into
>> arch-utils.c (like we have gdbarch_from_bfd and gdbarch_find_by_info),
>> which just does a lookup from tdesc.
>
> One thing I would like to add: I presume that this process
> (gdbarch_find_by_info) is somewhat expensive.  Is there an easy way to
> short-circuit things earlier?  Maybe if we detect that a thread has the
> same target desc id as before, we can avoid recomputing the gdbarch?
> Or, we can cache the gdbarch in the remote_target.

Or could we cache the gdbarch in the tdesc itself?  As you pointed out
for the previous patch, passing the same XML string will result in the
same tdesc object.  So if we had gdbarch_from_tdesc, this can do the
expensive gdbarch lookup, then store the gdbarch in the tdesc object.

Next time we call gdbarch_from_tdesc we can just check for a cached
gdbarch within the tdesc and return that...

...maybe?

Thanks,
Andrew




>                                                      The
> remote_target::m_tdescs would hold both the target desc and
> corresponding gdbarch as values, instead of just the target desc.
> Actually, maybe the remote target wouldn't need to hold the target_desc
> at all, once it has the gdbarch.  Other than maybe for lifetime reasons,
> which are discussed with the previous patch.
>
> Simon