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

[Luis Machado <luis.machado@arm.com>]

On 2/10/23 15:04, Tom Tromey wrote:
> Luis> But it is also a larger effort that has to revamp some things in
> Luis> gdb's type system to allow for sizeless types, and that also has
> Luis> implications in other areas of gdb.
> 
> I doubt I understand the problem here, but we do have dynamic types and
> dynamic type resolution now.  This lets you express a type's size,
> offsets of members, and even fields (via variant parts) by referring to
> other members of the object.

In summary, we need to define a vector register with size equal to the value of a particular
register (vg).

With every distinct value of that register, you'll have a distinct size in the register buffer, core
files, remote packet etc.

We do have dynamic types, but I don't particularly remember having a type that has a size defined by some
other entity outside of the type system, like a register (or dwarf register).

> 
> Luis> I'd be happy with an intermediate solution like what Thiago put
> Luis> together. It would solve a long-standing issue for SVE and
> Luis> gdbserver and it seems simpler at this point, plus Thiago already
> Luis> put the effort to write the code.
> 
> I haven't followed this discussion, but with the remote protocol,
> whatever we do now will be baked in forever.  So, it's worth spending
> extra time up front to get a really solid approach.  (I'm not saying
> this isn't, just pointing out that there's a long-term cost.)

Sure, but we can always add feature checks for that and fallback to known RSP if a particular feature isn't supported.

The approach Thiago took was, at one point, deemed the appropriate way to get dynamic vector lengths working in gdbserver. So some
amount of thought was put into it already.

I think there are two separate issues here. Per-thread target descriptions/gdbarch and the problem with dynamic vector lengths.

Realistically, having per-thread target descriptions/gdbarch seems like a more relevant feature at this point. It would allow
threads to have different architectures, and I think that is a good addition going forwards. Cell BE made use of this, but the
port has been removed now. It might also be useful for heterogeneous debugging, where you have cores of different architectures.

A separate issue is the one with the SVE dynamic vector length. We did have a chance to make gdb cope with sizeless types when SVE was
initially put together. But at the time it was deemed best to do (potentially) smaller adjustments to make it work for the native case. As a result,
the code we have now handles these changes via per-thread target descriptions.

I suppose AMX has the same issue, but I'm not sure how it was implemented. I remember reading about using a fixed-size buffer, but I haven't
followed that discussion closely.

So if we have other ports that could benefit from such a change to better handle types defined based on external entities (registers, variables etc), I guess
it would make sense to explore that possibility. Otherwise, if we're only trying to solve the particular case of SVE, coming up with a completely new design
might be a bit too much.

Just my $0.02.

> 
> Tom