[Lldb-commits] [PATCH] D82863: [LLDB] Add support to resize SVE registers at run-time

Mon Oct 5 01:23:29 PDT 2020

omjavaid added a comment.

@labath
I am just back from holiday and was hoping for Jason to give his advice in this. I am wondering how we can move forward on this.
I have added a some information from GDB inline.

In D82863#2254423 <https://reviews.llvm.org/D82863#2254423>, @labath wrote:

> I'd like to also pull in Jason for this, since this is really the trickiest part of the whole patchset.
>
> What this patch essentially does is bake in the knowledge of the arm sve registers and their various configurations into the lldb client (and the `DynamicRegisterInfo` class in particular). Before we go into the implementation details, we should answer the question whether we are ok with that.
>
> I am personally fine with that (if it gets encapsulated a bit better), because we can't avoid knowing about the registers of some architecture for various other reasons (core file debugging, eh_frame parsing, stubs which don't support qRegisterInfo, etc.). In fact, I'd be very happy if this got us closer towards a state where the stub does not need to send eh_frame and other register numbers over. Also, hardcoding may be the only way to get reasonable performance out of this, since a fully generic solution of asking about the register information after every stop would likely be prohibitively slow (well.. I suppose we could come up with some way of letting the stub to notify us when the register configuration has changed).
>
> I believe Jason is also ok some hardcoding, in principle. However,
> a) I don't want to speak for him,
> b) there's still a lot of details to be worked out.
>
> For example, one of the ideas floated around previously was based on the client and server communicating 4 things about each register:
>
> - name
> - the register number (for `p` packets, etc.)
> - size
> - offset (for e.g. `g` packet)
>
> The register name and number are fine, but the other two things are sort of variable with SVE. The register size was mainly there as a cross-check, and so we could conceivably just drop it from the list (or use the max value or some other placeholder for sve registers in particular). But that still leaves the question of the `g` offsets...

There are two different things we are looking at in this scenario:

1. Exchange of register information via RegisterInfo or XML packet at inferior creation
2. Register size/offset update mechanism during execution on every stop.

Reaching an optimal solution dropping extra information in both above cases is quite a challenge. I have been thinking about ways to drop offset and only way right now is to make LLDB register numbers act as sequence numbers and offset can be calculated based on the size of next in line register and previous value of offset. However challenge in this case (we discussed before during review of an earilier patch) was dynamic selection of register sets. Some register sets may be active some may not be active and it will make things quite tricky.
If we look at the eh_frame, dwarf reg numbers implementation in GDB its a similar mess there as well although its not kept inside register information but its being dealt with hardcoded in various areas of code. GDB also supports complex register type description as part of target XML which luckily we are not doing at the moment.

> It might be interesting data point to look at how the sve registers are described in gdb's target.xml descriptions.

GDB uses dynamically generated target XMLs now which were previously static. Target XML is generated based on the value of scale, which is no of chunks of 128 Bits in a Z register.
https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdb/features/aarch64-sve.c;h=e4361b07a4d47282c5515846896638cc4caf97f5;hb=HEAD#l25

Furthermore, GDB keeps a list of target descriptions for every combination of (vq, pauth) where pauth is flag telling if pointer authentication feature is supported while vq is vector length quad (multiples of 128bits). 
https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdb/aarch64-tdep.c;h=cbc7038dbba9472a12a3ae927bbb0937b10b2bdd;hb=HEAD#l3284

On gdbserver side similar to what is proposed for LLDB, GDB also exchanges vector length information using expedited registers list and updates target descriptions based on vg (vector granule register) value.
https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdbserver/linux-aarch64-tdesc.cc;h=897fbb43bd28ddf44c69d4162dda43c2589b060f;hb=HEAD#l35

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82863/new/

https://reviews.llvm.org/D82863