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

Thiago Jung Bauermann via Gdb-patches
2023-02-10T03:29:37Z

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.

> 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.

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.

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

--
Thiago