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 03:29, Thiago Jung Bauermann wrote:
> 
> Simon Marchi <simark@simark.ca> writes:
> 
>>> That is, assuming we continue with the thread-specific tdesc approach
>>> rather than the one which expands tdescs to allow describing one
>>> register's type in terms of another one. I'll revisit my notes and think
>>> more about this.
>>
>> Can we expand about this idea?  I think I like it, but I don't see 100%
>> how it would work.
> 
> Sorry, I can't expand much on it. I like it too, and as I mentioned in
> another email I spent some time investigating how it could be done but
> I wasn't able to make progress so I decided to do the per-thread tdesc
> implementation instead.
> 
> I would be willing to try again but I would need help with high-level
> design.
> 

My take on it is that it is he appropriate solution, and it would allow us to have a single target description for all the threads.

But it is also a larger effort that has to revamp some things in gdb's type system to allow for sizeless types, and that also has
implications in other areas of gdb.

Also, quite a bit of effort was put into supporting dynamic vector lengths mid-execution for SVE in native gdb, including
some new target hooks to adjust the architecture and the register cache format.

Changing this also means having to support the debugging stubs out there that already support SVE target descriptions. One can say
those stubs are not fully functional in terms of supporting dynamic vector lengths mid-execution, but they already produce target descriptions
in the current format (gdbserver is one of those stubs and QEMU is probably the second most important).

I'd be happy with an intermediate solution like what Thiago put together. It would solve a long-standing issue for SVE and gdbserver and it seems simpler at this point,
plus Thiago already put the effort to write the code.

>> I can imagine a vector of registers whose size
>> depends directly on the value of some other register that comes before,
>> like:
>>
>>    <vector id="vec" type="some_type" count="some_other_register"/>
>>
>> Here, "some_other_register" would be a scalar register that comes before
>> "vec", and whose value dictates directly the number of elements of
>> "vec".  But if you wanted to say that the number of elements in "vec" is
>> the value of some_other_register, times 2?  I guess we could write:
>>
>>    <vector id="vec" type="some_type" count="some_other_register * 2"/>
>>
>> .. but then we get in the realm of defining a grammar, building a
>> parser / evaluator, etc.
> 
> We could rein complexity in by supporting only the simplest of
> expressions, e.g. only a very rigid form such as “<operand 1> <op>
> <operand 2>” where <op> is one of the basic arithmetic operations.
> If that turns out to not be enough then we can increasingly support more
> complex operations.
> 
>> The type of the vector elements needs to be dynamic too, how do
>> we define that?
> 
> This is the part where I got stuck, especially on how to make GDB's type
> system allow expressing such a type.
> 
>> If the number of possibilities is known and static, we could have some
>> kind of "variant" type, where we list all the possible types, and select
>> among them at runtime based on the value of a preceding register.
> 
> Yes, in the case of SVE it's known and static. The maximum vector length
> is an architectural feature of the processor, and GDB/gdbserver can get
> it via ptrace in the NT_ARM_SVE regset. And it's always a multiple of
> 16.
> 

SME is a bit more strict with the allowed vector lengths. It is always a power of 2 between 128 and 2048 bits inclusive.

So in practice 128/256/512/1024/2048 bits.

> It's an interesting idea. Perhaps it's enough, at least for SVE?
> 
>> If I understand correctly, all of this makes it so the size of the
>> response to the g packet will be dynamic too?
> 
> We /could/ set the size of the g packet to always correspond to the
> largest vector length possible but it would be a big overhead,
> especially if there are many threads involved.

Or we could use the opportunity to break free from the g/G packet restrictions and go for a more flexible format while at it.

Given most of the fields contained in these big registers is 0 or same value, there is potential for quite a bit of compression.

Just an idea, while we're throwing ideas out there.

> 
> So in practice yes, it will be dynamic if we can help it.
>