[Lldb-commits] [lldb] RFC PR: Refactor AArch64 Linux native register context (PR #193174)

[David Spickett via lldb-commits]

DavidSpickett wrote:

> I want to spend a bit more time reading the changes in detail especially around the SVE SME etc paths before I give more concrete comments but overall this seems like a positive direction to me.

Thanks!

The SVE and SME paths should be the same as before, with the use of a couple of the lookup functions. Possibly I can integrate them with the rest, but I thought for now it was best to isolate the unique handling and make it easier to see when reading the code.

The escape hatch will always be hand writing the handling, but it will be clear what's normal handling and what isn't. Whereas now, it's all mixed together in these giant if/else chains.

> one more thing I am curious about is if this shape also fits the future direction of AArch64 architecture since you may have a better view of what is coming next in Arm and whether this model will scale well for that

Everything I know of is going to fit into the straightforward path. That being that it has a fixed size and you read/write it via a single ptrace set. Given that the majority of registers now are straightforward, we'll always have a use for that path.

For anything that is as unique as SVE/SME we may have to have bespoke handling again, but I don't think we can anticipate that now. The refactor doesn't prevent you from having a bespoke handler, so we always have some way to make it work.

To really break this design I think something would have to change how all registers work. For instance what if they all became banked registers with N copies of each thing. Something that fundamental we can't anticipate now, and support for such a feature would be much larger than the changes to this specific class.

Then there's adding features to the class itself. For example caching, if we didn't already have it that is. Maybe some smart form of it or batching writes until the last second, stuff like that. As this refactor is mostly a formalisation of what we're already doing, I don't think it makes it any harder to extend the class. It gets "most" things going through the same functions, so hooking into those will be easier.

In short: I don't know of anything unusual coming, and anything sufficiently disruptive is not worth guessing at now.

https://github.com/llvm/llvm-project/pull/193174