Re: [PATCH v3 4/8] gdbserver/linux-aarch64: When thread stops, update its target description

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

Luis Machado <luis.machado@arm.com> writes:

> On 2/6/23 20:29, Pedro Alves wrote:
>> On 2023-02-04 3:21 p.m., Thiago Jung Bauermann via Gdb-patches wrote:
>>>
>>> Luis Machado <luis.machado@arm.com> writes:
>>>
>>>> On 2/2/23 03:47, Simon Marchi wrote:
>>>>> Ok.  Would it work if a new thread initially inherited the tdesc from
>>>>> its process?
>>>>>
>>>>
>>>> It should be fine because the first time we fetch a process target
>>>> description, it is eventually obtained from the first and only thread.
>>>> So the SVE vector length should be correct.
>>>>
>>>> Any subsequent attempts to use the process' target description (the
>>>> first one we obtained), after further stops, may end up using an
>>>> incorrect description.
>>>>
>>>> I think this is handled correctly by the target architecture target
>>>> hook though. But there are other places where this is potentially
>>>> incorrect.
>>>>
>>>> For example...
>>>>
>>>> - When using gcore to dump a core file, GDB only dumps a single target
>>>> description. While this might be correct for a target with a fixed
>>>> target description or a AArch64 target that doesn't support SVE, it
>>>> likely won't be correctly for one AArch64 target supporting SVE if its
>>>> threads changed vector length mid-execution. Either we emit target
>>>> description notes by thread, or we don't emit a target description
>>>> note for those cases.
>>>>
>>>> - When loading the above/older gcore core files back, GDB will use a
>>>> potentially incorrect target description. If we decide to emit
>>>> per-thread target descriptions, it should be fine. Otherwise we may
>>>> need to have a "thread architecture" hook for core files as well.
>>>>
>>>> - The remote has no concept of a thread architecture (Thiago is
>>>> addressing this with this patch series).
>>>>
>>>> - AArch64 frames may have slightly different vg values, which means
>>>> their gdbarches are different as well.
>>>>
>>>> Given the differences between two gdbarches are small, we mostly get
>>>> away with it. But if there are further differences (different hooks,
>>>> for example), I fear we may run into a situation where we use an
>>>> incorrect gdbarch to call a particular hook.
>>>
>>> Indeed, good points! Thank you for bringing them up. I can address core
>>> file dumping/loading after this series.
>>>
>>> Regarding frames with different vg values, it's important to be aware of
>>> this discrepancy but IMHO it makes sense to work on it when it becomes
>>> a problem...
>>>
>> Yeah, one thought that keeps crossing my mind is if really modeling
>> all this stuff as different target descriptions is really the best
>> approach. The Intel AMX support posted on the list last year also ran
>> into a similar problem, with the matrix registers height/width
>> changing at runtime, and it is impractical (or really, it really
>> smells like the wrong approach) to have different target descriptions
>> for every potential matrix size. Which is not unlike different SVE
>> sizes. It feels like a single tdesc should be able to be a bit more
>> dynamic. It's a bit funny that ptrace manages to work with a single
>> registers interface, while we don't.
>
> My understanding is that this was a bit hard to justify back when SVE
> was implemented, as it would have to touch some other bits of the type
> system to create a sizeless type for SVE vectors, where the size would
> be determined by context.

When I started working on these patches I read some older discussions on
the topic of SVE in the mailing list archives and I saw this idea.

So before going down the per-thread target description route I spent
some time trying to figure out a way to make the vector register size a
function of the contents of another register (a pseudo-register, in the
case of SVE), but I failed to see how I could do it.

I'm open to giving it another try but I would need some guidance. It
doesn't need to be detailed instructions, but a high level idea of how
it can be done would be very helpful.

-- 
Thiago