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

Luis Machado via Gdb-patches
2023-02-03T11:32:16Z

On 2/1/23 20:20, Simon Marchi via Gdb-patches wrote:
>> 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

We already do it in gdb/aarch64-tdep.c:aarch64_gdbarch_init by checking if we have something that can be reused:

/* If there is already a candidate, use it. */
for (gdbarch_list *best_arch = gdbarch_list_lookup_by_info (arches, &info);
best_arch != nullptr;
best_arch = gdbarch_list_lookup_by_info (best_arch->next, &info))
{
aarch64_gdbarch_tdep *tdep
= gdbarch_tdep<aarch64_gdbarch_tdep> (best_arch->gdbarch);
if (tdep && tdep->vq == vq)
return best_arch->gdbarch;
}

It is indeed an expensive process.

> same target desc id as before, we can avoid recomputing the gdbarch?
> Or, we can cache the gdbarch in the remote_target. 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
>