[LLDB] Add support for Arm64/Linux dynamic register sets

[omjavaid]

Summary

This is the first patch in series for supporting Arm64 dynamic features in LLDB. Arm64 has dynamic features like SVE, Pointer Authentication and MTE which means LLDB needs to decide at run time which registers it needs to pull in for the current executable based on underlying support for a certain feature.

This patch makes necessary adjustments to RegisterInfoPOSIX_arm64 to make way for dynamic register infos and dynamic register sets. This patch does not add any new feature per se but makes way for adding new dynamic register sets in following up patches.

[DavidSpickett]

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

454

return GetRegisterInfo().IsSVEReg(reg) ?

1120

I spent a good few minutes getting my head around this logic but tell me if I missed something. (a comment explaining it would be great)

• If we don't have a cached sve header and we don't know that SVE is disabled...
• Try to read the SVE header
• if it succeeded and we're doing this read for the first time, setup register infos
• otherwise it failed so SVE must be disabled
• if it succeeded (first time or otherwise) query the vector length (this is the bit that tripped me up trying to think how you'd refactor it)
• if we did have a cached sve header, we'd already know the config, no point reading it again
• if it's disabled, then it's disabled, same thing.

I think that means you're missing the corner case where we have SVEState::Full say, but then the header fails to read. Is that possible on a real system though? I guess not.

And vector length can change at runtime, correct?

lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp

43

return m_register_info_up->IsSVEReg(reg); ?

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp

243

Should the last condition be <? Given:

m_per_regset_regnum_range[FPRegSet] = std::make_pair(fpu_v0, fpu_fpcr);

Where the last index is the first non FP register.

258

Comments here would really help.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

93

Just curious, is "mode" the term we use for the SVE length? I guess because it's going to be some multiples of 128 isn't it, not an arbitrary bit length.

[omjavaid]

thanks @DavidSpickett for the review. I have updated diff incorporating you suggestions.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

454

Ack.

1120

I have updated the comment to reflect what this piece of code tries to do.

Register Infos are maintained by debuggers per process however for SVE we may have per thread register infos but what I understood from linux documentation is for a process to support SVE ptrace call to NT_ARM_SVE should succeed on first stop. This is what we are using to enabled or disabled SVE at startup.

if SVEState::Full is full and we fail to read NT_ARM_SVE at some stage for any reason. we can do try to read again on subsequent stop.

lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp

43

Ack.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp

243

m_per_regset_regnum_range includes start and end register number of a register set with start and end inlucded.

fpu_fpcr is included in FPU regset. On non SVE targets Vx, Dx. Sx register plus fpcr and fpsr are part of FPU regset.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

93

We had chosen mode when we started but then moves away from this terminology. I ve fixed it in next update.

[labath]

I'm sorry, my response times are pretty slow these days.

I'm thinking about this ConfigureRegisterInfos business. I get that the vector length is variable, and so we need to refresh it after every stop. However, the set of enabled extensions seems more static.

Is it possible for that to change during the lifetime of the process? I'd guess not, because otherwise we'd have to also resend the register lists after every stop. And, if that's the case, I'm wondering if there's a way to reflect this static-ness in the code. For example, by doing this setup in the constructor, instead of a late ConfigureRegisterInfos call. IIRC, the register contexts are created when the thread is stopped, so it should be possible to fetch the information about supported registers quite early.

What do you think?

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

17–18

let's not use macros here.

[omjavaid]

In D96458#2566347, @labath wrote:

I'm sorry, my response times are pretty slow these days.

I'm thinking about this ConfigureRegisterInfos business. I get that the vector length is variable, and so we need to refresh it after every stop. However, the set of enabled extensions seems more static.

Is it possible for that to change during the lifetime of the process? I'd guess not, because otherwise we'd have to also resend the register lists after every stop. And, if that's the case, I'm wondering if there's a way to reflect this static-ness in the code. For example, by doing this setup in the constructor, instead of a late ConfigureRegisterInfos call. IIRC, the register contexts are created when the thread is stopped, so it should be possible to fetch the information about supported registers quite early.

What do you think?

Yes that is doable. I ll move ConfigureRegisterInfos part into constructor.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

17–18

Ack.

[omjavaid]

This moves ConfigureRegisterInfos into constructor.

[rovka]

Hi Omair,

I had a look and I think the commit message is slightly misleading because it says "Arm64 has dynamic features like SVE, Pointer Authentication and MTE", but then you don't set m_reg_infos_is_dynamic to true for SVE. This got me a bit confused at first. Maybe it would help to elaborate a bit on this point in the commit message (and maybe also in the comments if you think it makes sense).

I also have a few nits inline.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

82

I was about to suggest using lldb_private::Flags for this, but after looking a bit more through the code it's not clear how this is intended to be used. The definition of eRegsetEnableSVE doesn't look flag-like at all (I would expect to see 1 << 1 rather than just plain 1, to make it clear what future values should look like), and also in ConfigureRegisterContext you check if (opt_regsets > eRegsetEnableSVE), which to me doesn't seem very idiomatic for working with flags.

What do you think about increasing the level of abstraction a bit and using a small wrapper class for the regset options, that can answer directly questions like IsRegsetDynamic()?

89

Nitpick: You should hoist the call out of the if, so it's easier to add other regsets in the future.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

129

Nitpick: Please use square brackets instead of parantheses, otherwise it's confusing (parentheses suggest an open interval).

[omjavaid]

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

82

I have given this a thought and although Flags class doesnt completely fit in we still can adjust our logic to use it. I guess using Flags will look neat. I ll update. Thanks

89

This piece will be updated in a child patch of this series where we add logic for Pauth and MTE regsets.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

129

Ack.

[omjavaid]

This update fixes review comments highlighted by @rovka

[labath]

In D96458#2578760, @omjavaid wrote:

In D96458#2566347, @labath wrote:

I'm sorry, my response times are pretty slow these days.

I'm thinking about this ConfigureRegisterInfos business. I get that the vector length is variable, and so we need to refresh it after every stop. However, the set of enabled extensions seems more static.

Is it possible for that to change during the lifetime of the process? I'd guess not, because otherwise we'd have to also resend the register lists after every stop. And, if that's the case, I'm wondering if there's a way to reflect this static-ness in the code. For example, by doing this setup in the constructor, instead of a late ConfigureRegisterInfos call. IIRC, the register contexts are created when the thread is stopped, so it should be possible to fetch the information about supported registers quite early.

What do you think?

Yes that is doable. I ll move ConfigureRegisterInfos part into constructor.

There's still one ConfigureRegisterInfos call in the RegisterContextCorePOSIX_arm64::ConfigureRegisterContext function. Is that an omission, or is it intentional (i.e., needed to support some arm feature)? Because, if that's intentional, then the moving the setup to the constructor does not achieve what I wanted, as the set of registers can be overridden afterwards. It also means we need to have a bigger discussion about how to communicate the changed registers between the client and server. OTOH, if it's not intentional, then I'd like to remove that call, to make it obvious that the set of registers cannot change (only their length, for sve registers and such).

So, let me try to ask a direct question: Is there any situation in which the set of registers accessible to the inferior (and lldb-server) can change during the lifetime of a single process. If so, what is it?

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp

258

This should a const reference or just a plain value.

265

We generally don't use braces around simple statements like this.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

31

mixing signed and unsigned constants looks weird. Maybe just use ~3?

[omjavaid]

This comment was removed by omjavaid.

[omjavaid]

In D96458#2613244, @labath wrote:

In D96458#2578760, @omjavaid wrote:

In D96458#2566347, @labath wrote:

I'm sorry, my response times are pretty slow these days.

I'm thinking about this ConfigureRegisterInfos business. I get that the vector length is variable, and so we need to refresh it after every stop. However, the set of enabled extensions seems more static.

Is it possible for that to change during the lifetime of the process? I'd guess not, because otherwise we'd have to also resend the register lists after every stop. And, if that's the case, I'm wondering if there's a way to reflect this static-ness in the code. For example, by doing this setup in the constructor, instead of a late ConfigureRegisterInfos call. IIRC, the register contexts are created when the thread is stopped, so it should be possible to fetch the information about supported registers quite early.

What do you think?

Yes that is doable. I ll move ConfigureRegisterInfos part into constructor.

There's still one ConfigureRegisterInfos call in the RegisterContextCorePOSIX_arm64::ConfigureRegisterContext function. Is that an omission, or is it intentional (i.e., needed to support some arm feature)? Because, if that's intentional, then the moving the setup to the constructor does not achieve what I wanted, as the set of registers can be overridden afterwards. It also means we need to have a bigger discussion about how to communicate the changed registers between the client and server. OTOH, if it's not intentional, then I'd like to remove that call, to make it obvious that the set of registers cannot change (only their length, for sve registers and such).

So, let me try to ask a direct question: Is there any situation in which the set of registers accessible to the inferior (and lldb-server) can change during the lifetime of a single process. If so, what is it?

ConfigureRegisterContext is called only once in the lifetime of a core from RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change during execution which is what made basis of this change. for NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out of configure register context because it will be called again and again during execution. But for RegisterContextCorePOSIX_arm64 we call it once in the constructor so its safe to keep the function.

[labath]

In D96458#2613894, @omjavaid wrote:

ConfigureRegisterContext is called only once in the lifetime of a core from RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change during execution which is what made basis of this change. for NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out of configure register context because it will be called again and again during execution. But for RegisterContextCorePOSIX_arm64 we call it once in the constructor so its safe to keep the function.

Ok, I understand what's happening now -- thanks for re-iterating. I have managed to miss the fact that this patch deals with both core file and live register contexts.

In that case, I'd like to go one step further, and remove the "configuration" operation from the RegisterInfoPOSIX_arm64 class as well (by making it a part of the construction). It should be possible to do that by fetching the information needed to determine the registers before the class is instantiated. For the live context, that could be done inside the CreateHostNativeRegisterContextLinux function. For the core file context, we could create a similar factory function as well. I.e. move the construction of RegisterInfoPOSIX_arm64 from ThreadElfCore into some static function inside RegisterContextCorePOSIX_arm64 -- this function could examine the core data to determine the registers and construct the appropriate info class.

[omjavaid]

In D96458#2613948, @labath wrote:

In D96458#2613894, @omjavaid wrote:

ConfigureRegisterContext is called only once in the lifetime of a core from RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change during execution which is what made basis of this change. for NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out of configure register context because it will be called again and again during execution. But for RegisterContextCorePOSIX_arm64 we call it once in the constructor so its safe to keep the function.

Ok, I understand what's happening now -- thanks for re-iterating. I have managed to miss the fact that this patch deals with both core file and live register contexts.

In that case, I'd like to go one step further, and remove the "configuration" operation from the RegisterInfoPOSIX_arm64 class as well (by making it a part of the construction). It should be possible to do that by fetching the information needed to determine the registers before the class is instantiated. For the live context, that could be done inside the CreateHostNativeRegisterContextLinux function. For the core file context, we could create a similar factory function as well. I.e. move the construction of RegisterInfoPOSIX_arm64 from ThreadElfCore into some static function inside RegisterContextCorePOSIX_arm64 -- this function could examine the core data to determine the registers and construct the appropriate info class.

hmm .. in that case we will have to defer creation of RegisterInfoPOSIX_arm64 as you said above. I will create a function that will allow us to update unique_ptr m_register_info_up in RegisterContextPOSIX_arm64 and also another function for doing the same for m_register_info_interface_up object in NativeRegisterContextRegisterInfo class. Rest will be same as you suggested above.

[labath]

In D96458#2614076, @omjavaid wrote:

In D96458#2613948, @labath wrote:

In D96458#2613894, @omjavaid wrote:

ConfigureRegisterContext is called only once in the lifetime of a core from RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change during execution which is what made basis of this change. for NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out of configure register context because it will be called again and again during execution. But for RegisterContextCorePOSIX_arm64 we call it once in the constructor so its safe to keep the function.

Ok, I understand what's happening now -- thanks for re-iterating. I have managed to miss the fact that this patch deals with both core file and live register contexts.

In that case, I'd like to go one step further, and remove the "configuration" operation from the RegisterInfoPOSIX_arm64 class as well (by making it a part of the construction). It should be possible to do that by fetching the information needed to determine the registers before the class is instantiated. For the live context, that could be done inside the CreateHostNativeRegisterContextLinux function. For the core file context, we could create a similar factory function as well. I.e. move the construction of RegisterInfoPOSIX_arm64 from ThreadElfCore into some static function inside RegisterContextCorePOSIX_arm64 -- this function could examine the core data to determine the registers and construct the appropriate info class.

hmm .. in that case we will have to defer creation of RegisterInfoPOSIX_arm64 as you said above. I will create a function that will allow us to update unique_ptr m_register_info_up in RegisterContextPOSIX_arm64

That would make the registers of a RegisterInfoPOSIX_arm64 instance immutable (which is good), but that function would allow one to mutate the RegisterContextPOSIX_arm64 class in the middle of its lifetime by swapping the register info backing it (which is exactly what I'm trying to avoid). I'm trying to create an apis that is impossible/hard to use incorrectly. I'd like to avoid this kind of "configuration" functions unless they are really necessary. I could be wrong, but right now I don't see a reason why they'd be necessary.

[omjavaid]

In D96458#2614101, @labath wrote:

In D96458#2614076, @omjavaid wrote:

In D96458#2613948, @labath wrote:

In D96458#2613894, @omjavaid wrote:

ConfigureRegisterContext is called only once in the lifetime of a core from RegisterContextCorePOSIX_arm64 constructor. A process registers cannot change during execution which is what made basis of this change. for NativeRegisterContextLinux_arm64 I moved the ConfigureRegisterInfos logic out of configure register context because it will be called again and again during execution. But for RegisterContextCorePOSIX_arm64 we call it once in the constructor so its safe to keep the function.

Ok, I understand what's happening now -- thanks for re-iterating. I have managed to miss the fact that this patch deals with both core file and live register contexts.

In that case, I'd like to go one step further, and remove the "configuration" operation from the RegisterInfoPOSIX_arm64 class as well (by making it a part of the construction). It should be possible to do that by fetching the information needed to determine the registers before the class is instantiated. For the live context, that could be done inside the CreateHostNativeRegisterContextLinux function. For the core file context, we could create a similar factory function as well. I.e. move the construction of RegisterInfoPOSIX_arm64 from ThreadElfCore into some static function inside RegisterContextCorePOSIX_arm64 -- this function could examine the core data to determine the registers and construct the appropriate info class.

hmm .. in that case we will have to defer creation of RegisterInfoPOSIX_arm64 as you said above. I will create a function that will allow us to update unique_ptr m_register_info_up in RegisterContextPOSIX_arm64

That would make the registers of a RegisterInfoPOSIX_arm64 instance immutable (which is good), but that function would allow one to mutate the RegisterContextPOSIX_arm64 class in the middle of its lifetime by swapping the register info backing it (which is exactly what I'm trying to avoid). I'm trying to create an apis that is impossible/hard to use incorrectly. I'd like to avoid this kind of "configuration" functions unless they are really necessary. I could be wrong, but right now I don't see a reason why they'd be necessary.

We cannot calculated register set configuration untill we create register context. Both RegisterContextPOSIX_arm64 and NativeRegisterContextRegisterInfo are base class objects for their corresponding register contexts and its not trivial to make them immutable without serious refactoring. I am going to try reading SVE header using a static func as you suggested above but we ll also need one for NativeRegisterContextLinux_arm64 which requires reading SVE state for register config.

[labath]

Would something like

reginfo.diff9 KBDownload

do the trick? It needs a bit of cleanup (I haven't actually removed ConfigureRegisterInfos function yet -- I just moved it right next to the reginfo creation), but I think should make it clear where I'm going with this.

[omjavaid]

In D96458#2618846, @labath wrote:

Would something like

reginfo.diff9 KBDownload

do the trick? It needs a bit of cleanup (I haven't actually removed ConfigureRegisterInfos function yet -- I just moved it right next to the reginfo creation), but I think should make it clear where I'm going with this.

Yes this should work. Thanks for the prompt response. May I use this code in follow up?

[labath]

Yes, definitely.

[omjavaid]

This update incorporates changes written by @labath

[labath]

Thanks. This looks much better, but there is still one thing which bugs me about the register info constructor. Currently, there are three paths through that constructor:

1. when we don't have any fancy registers (this is the original one)
2. when we have just SVE (added with the sve support)
3. when we have pauth et al. (added now)

Do we need all three of them? Is there anything which makes SVE special that it deserves its own register info array? Could it be just another "dynamic" register set like the other features? (If that's true, I might consider also removing the first code path, making it just a special case of an empty set of dynamic features.)

I also have some inline comments, but there are just simple stylistic issues, I hope.

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp

205–211

It would be better to initialize these in the else branch of the if (m_opt_regsets.AllSet(eRegsetMaskSVE)) statement

215

Can we make it so that m_register_info_count always contains a valid value?

218

ArrayRef<RegisterInfo> reginfo;

221–222

reginfo = makeArrayRef(g_register_infos_arm64_sve_le, sve_ffr);

227–228

ditto

231–232

llvm::copy(reginfo, std::back_inserter);

233–234

std::copy_n(regset_start, m_register_set_count, ...)

243

I was also surprised at the <, as ranges in c++ are normally half-open. It may be better to stick with that, even if it means adding a +1 to the make_pair statement.

[omjavaid]

In D96458#2624962, @labath wrote:

Thanks. This looks much better, but there is still one thing which bugs me about the register info constructor. Currently, there are three paths through that constructor:

1. when we don't have any fancy registers (this is the original one)
2. when we have just SVE (added with the sve support)
3. when we have pauth et al. (added now)

Do we need all three of them? Is there anything which makes SVE special that it deserves its own register info array? Could it be just another "dynamic" register set like the other features? (If that's true, I might consider also removing the first code path, making it just a special case of an empty set of dynamic features.)

I also have some inline comments, but there are just simple stylistic issues, I hope.

I agree with your about SVE being dynamic I just didn't go for the change because I was being a little conservative about changing existing functionality. But I think If we look at the changes now making SVE dynamic seems right thing to do. Let me make the change and update this rev.

[omjavaid]

In D96458#2625554, @omjavaid wrote:

In D96458#2624962, @labath wrote:

Thanks. This looks much better, but there is still one thing which bugs me about the register info constructor. Currently, there are three paths through that constructor:

1. when we don't have any fancy registers (this is the original one)
2. when we have just SVE (added with the sve support)
3. when we have pauth et al. (added now)

Do we need all three of them? Is there anything which makes SVE special that it deserves its own register info array? Could it be just another "dynamic" register set like the other features? (If that's true, I might consider also removing the first code path, making it just a special case of an empty set of dynamic features.)

I also have some inline comments, but there are just simple stylistic issues, I hope.

I agree with your about SVE being dynamic I just didn't go for the change because I was being a little conservative about changing existing functionality. But I think If we look at the changes now making SVE dynamic seems right thing to do. Let me make the change and update this rev.

@labath
I forgot to mention but recalled after looking at the code that the major problem/hurdle is g_contained_* and *_invalidates reg list. In case of SVE V, D and S registers are contained by Z register and therefore we will have to update their contained and value reg list accordingly. Only registers declaration which we can skip out of the SVE's register info array are the GPRs X and W. Larger the register set more complicated handling of its dynamic register set will be.
We have three options here:

1. Keep current state and use separate register info array in case of SVE (Simple solution)
2. We skip the GPRs out of SVE's register info array and declare all vector registers in SVE's register info array using appropriate contained and invalidate register lists.

Looking at this now I dont see this much of advantage just for the sake of pulling out GPR declaration from SVE register info array. What do you think?

[labath]

Right, I see. The contained lists are going to make this trickier than I expected, and might even make the code more complicated. (Though this tradeoff will change if we ever end up with two optional regsets that need to mess with contained lists.)

Could we at least then structure the constructor code to avoid checking for SVE twice. Ideally, we would make this a two-step process:

1. select the "base" register list (either gpr+fpr, or gpr+fpr+sve)
2. add optional sets

Something like:

if (regsets & SVE) {
  m_register_set_p = reginfos_with_sve;
  // and similar for other variables
} else {
  m_register_set_p = reginfos_without_sve;
}
if (regsets & Dynamic) {
  m_dynamic_reg_infos.assign(m_register_set_p, m_register_set_count)
  if (regsets & pauth)
    m_dynamic_reg_infos.insert(end(), g_pauth_registers); // or whatever
  
  m_register_set_p = m_dynamic_reg_infos.data();
  // etc.
}

[omjavaid]

This update address review comments from @labath

[omjavaid]

This update further cleans up and removes static functions that calculated m_register_info_p GetRegisterInfoPtr and m_register_info_count GetRegisterInfoCount

[labath]

I very happy with how this has turned out. Thanks for your patience.

[mgorny]

This changed the API of RegisterInfoPOSIX_arm64 and broke the FreeBSD plugin. I'm going to try to fix it but next time it'd be nice if you checked that the class isn't used by something before making changes to its API.

lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp

NativeRegisterContextLinux_arm64::NativeRegisterContextLinux_arm64(
   m_fpu_is_valid = false;
   m_sve_buffer_is_valid = false;
   m_sve_header_is_valid = false;
 
   // SVE is not enabled until we query user_sve_header
   m_sve_state = SVEState::Unknown;
 }
 
 RegisterInfoPOSIX_arm64 &
 NativeRegisterContextLinux_arm64::GetRegisterInfo() const {
   return static_cast<RegisterInfoPOSIX_arm64 &>(*m_register_info_interface_up);
 }
 
 uint32_t NativeRegisterContextLinux_arm64::GetRegisterSetCount() const {
   return GetRegisterInfo().GetRegisterSetCount();
 }
 
 const RegisterSet *
 NativeRegisterContextLinux_arm64::GetRegisterSet(uint32_t set_index) const {
   return GetRegisterInfo().GetRegisterSet(set_index);
 }
 
 uint32_t NativeRegisterContextLinux_arm64::GetUserRegisterCount() const {
   uint32_t count = 0;

 bool NativeRegisterContextLinux_arm64::IsFPR(unsigned reg) const {
   if (GetRegisterInfo().GetRegisterSetFromRegisterIndex(reg) ==
       RegisterInfoPOSIX_arm64::FPRegSet)
     return true;
   return false;
 }
 
 bool NativeRegisterContextLinux_arm64::IsSVE(unsigned reg) const {
-  if (GetRegisterInfo().GetRegisterSetFromRegisterIndex(reg) ==
-      RegisterInfoPOSIX_arm64::SVERegSet)
+  if (GetRegisterInfo().IsSVEReg(reg))
     return true;
   return false;
 }
 
 uint32_t NativeRegisterContextLinux_arm64::NumSupportedHardwareBreakpoints() {
   Log *log(ProcessPOSIXLog::GetLogIfAllCategoriesSet(POSIX_LOG_BREAKPOINTS));
 
   LLDB_LOGF(log, "NativeRegisterContextLinux_arm64::%s()", __FUNCTION__);
Status NativeRegisterContextLinux_arm64::WriteAllSVE() {
 
   return WriteRegisterSet(&ioVec, GetSVEBufferSize(), NT_ARM_SVE);
 }
 
 void NativeRegisterContextLinux_arm64::ConfigureRegisterContext() {
   // Read SVE configuration data and configure register infos.
   if (!m_sve_header_is_valid && m_sve_state != SVEState::Disabled) {
     Status error = ReadSVEHeader();
-    if (!error.Success() && m_sve_state == SVEState::Unknown) {
-      m_sve_state = SVEState::Disabled;
-      GetRegisterInfo().ConfigureVectorRegisterInfos(
-          RegisterInfoPOSIX_arm64::eVectorQuadwordAArch64);
+    uint32_t opt_regset = ARM64_REGS_CONFIG_DEFAULT;
+    if (m_sve_state == SVEState::Unknown) {
+      if (error.Success()) {
+        opt_regset |= ARM64_REGS_CONFIG_SVE;
+        GetRegisterInfo().ConfigureRegisterInfos(opt_regset);
       } else {
+        m_sve_state = SVEState::Disabled;
+        GetRegisterInfo().ConfigureRegisterInfos(opt_regset);
+        return;
+      }
+    }
+
+    if (error.Success()) {
       if ((m_sve_header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_FPSIMD)
         m_sve_state = SVEState::FPSIMD;
       else if ((m_sve_header.flags & SVE_PT_REGS_MASK) == SVE_PT_REGS_SVE)
         m_sve_state = SVEState::Full;
 
       uint32_t vq = RegisterInfoPOSIX_arm64::eVectorQuadwordAArch64SVE;
       if (sve_vl_valid(m_sve_header.vl))
         vq = sve_vq_from_vl(m_sve_header.vl);
-      GetRegisterInfo().ConfigureVectorRegisterInfos(vq);
+
+      GetRegisterInfo().ConfigureVectorLength(vq);
       m_sve_ptrace_payload.resize(SVE_PT_SIZE(vq, SVE_PT_REGS_SVE));
     }
   }
 }
 
 uint32_t NativeRegisterContextLinux_arm64::CalculateFprOffset(
     const RegisterInfo *reg_info) const {
   return reg_info->byte_offset - GetGPRSize();
 }

lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp

 bool RegisterContextPOSIX_arm64::IsFPR(unsigned reg) {
   if (m_register_info_up->GetRegisterSetFromRegisterIndex(reg) ==
       RegisterInfoPOSIX_arm64::FPRegSet)
     return true;
   return false;
 }
 
 bool RegisterContextPOSIX_arm64::IsSVE(unsigned reg) const {
-  if (m_register_info_up->GetRegisterSetFromRegisterIndex(reg) ==
-      RegisterInfoPOSIX_arm64::SVERegSet)
+  if (m_register_info_up->IsSVEReg(reg))
     return true;
   return false;
 }
 
 RegisterContextPOSIX_arm64::RegisterContextPOSIX_arm64(
     lldb_private::Thread &thread,
     std::unique_ptr<RegisterInfoPOSIX_arm64> register_info)
     : lldb_private::RegisterContext(thread, 0),

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h

 //===-- RegisterInfoPOSIX_arm64.h -------------------------------*- C++ -*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERINFOPOSIX_ARM64_H
 #define LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERINFOPOSIX_ARM64_H
 
 #include "RegisterInfoAndSetInterface.h"
 #include "lldb/Target/RegisterContext.h"
 #include "lldb/lldb-private.h"
 #include <map>
 
+#define ARM64_REGS_CONFIG_DEFAULT 0x00
+#define ARM64_REGS_CONFIG_SVE 0x01
+
 enum class SVEState { Unknown, Disabled, FPSIMD, Full };
 
 class RegisterInfoPOSIX_arm64
     : public lldb_private::RegisterInfoAndSetInterface {
 public:
   enum { GPRegSet = 0, FPRegSet, SVERegSet };
 
   // AArch64 Register set FP/SIMD feature configuration
   enum {
     eVectorQuadwordAArch64,
     eVectorQuadwordAArch64SVE,
     eVectorQuadwordAArch64SVEMax = 256
   };
 
   // based on RegisterContextDarwin_arm64.h
   LLVM_PACKED_START
   struct GPR {
     uint64_t x[29]; // x0-x28
     uint64_t fp;    // x29
     uint64_t lr;    // x30
public:
 
   const lldb_private::RegisterSet *
   GetRegisterSet(size_t reg_set) const override;
 
   size_t GetRegisterSetCount() const override;
 
   size_t GetRegisterSetFromRegisterIndex(uint32_t reg_index) const override;
 
-  uint32_t ConfigureVectorRegisterInfos(uint32_t sve_vq);
+  void ConfigureRegisterInfos(uint32_t opt_regsets);
+
+  uint32_t ConfigureVectorLength(uint32_t mode);
 
   bool VectorSizeIsValid(uint32_t vq) {
     if (vq >= eVectorQuadwordAArch64 && vq <= eVectorQuadwordAArch64SVEMax)
       return true;
     return false;
   }
 
   bool IsSVEEnabled() const { return m_vector_reg_vq > eVectorQuadwordAArch64; }
 
+  bool IsSVEReg(unsigned reg) const;
   bool IsSVEZReg(unsigned reg) const;
   bool IsSVEPReg(unsigned reg) const;
   bool IsSVERegVG(unsigned reg) const;
 
   uint32_t GetRegNumSVEZ0() const;
   uint32_t GetRegNumSVEFFR() const;
   uint32_t GetRegNumFPCR() const;
   uint32_t GetRegNumFPSR() const;
   uint32_t GetRegNumSVEVG() const;
 
 private:
   typedef std::map<uint32_t, std::vector<lldb_private::RegisterInfo>>
       per_vq_register_infos;
 
   per_vq_register_infos m_per_vq_reg_infos;
 
   uint32_t m_vector_reg_vq = eVectorQuadwordAArch64;
 
   const lldb_private::RegisterInfo *m_register_info_p;
   uint32_t m_register_info_count;
+
+  const lldb_private::RegisterSet *m_register_set_p;
+  uint32_t m_register_set_count;
+
+  std::map<uint32_t, std::pair<uint32_t, uint32_t>> m_per_regset_regnum_range;
+
+  bool m_reg_infos_is_dynamic = false;
+
+  std::vector<lldb_private::RegisterInfo> m_dynamic_reg_infos;
+  std::vector<lldb_private::RegisterSet> m_dynamic_reg_sets;
 };
 
 #endif

lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp

default:
     assert(false && "Unhandled target architecture.");
     return 0;
   }
 }
 
 RegisterInfoPOSIX_arm64::RegisterInfoPOSIX_arm64(
     const lldb_private::ArchSpec &target_arch)
     : lldb_private::RegisterInfoAndSetInterface(target_arch),
       m_register_info_p(GetRegisterInfoPtr(target_arch)),
-      m_register_info_count(GetRegisterInfoCount(target_arch)) {
+      m_register_info_count(GetRegisterInfoCount(target_arch)),
+      m_register_set_p(g_reg_sets_arm64),
+      m_register_set_count(k_num_register_sets - 1) {
+  m_per_regset_regnum_range[GPRegSet] = std::make_pair(gpr_x0, gpr_w28);
+  m_per_regset_regnum_range[FPRegSet] = std::make_pair(fpu_v0, fpu_fpcr);
 }
 
 uint32_t RegisterInfoPOSIX_arm64::GetRegisterCount() const {
+  if (m_reg_infos_is_dynamic)
+    return m_register_info_count;
+
   if (IsSVEEnabled())
     return k_num_gpr_registers + k_num_fpr_registers + k_num_sve_registers;
 
   return k_num_gpr_registers + k_num_fpr_registers;
 }
 
 size_t RegisterInfoPOSIX_arm64::GetGPRSize() const {
   return sizeof(struct RegisterInfoPOSIX_arm64::GPR);
 }
 
 size_t RegisterInfoPOSIX_arm64::GetFPRSize() const {
   return sizeof(struct RegisterInfoPOSIX_arm64::FPU);
 }
 
 const lldb_private::RegisterInfo *
 RegisterInfoPOSIX_arm64::GetRegisterInfo() const {
   return m_register_info_p;
 }
 
 size_t RegisterInfoPOSIX_arm64::GetRegisterSetCount() const {
-  if (IsSVEEnabled())
-    return k_num_register_sets;
-  return k_num_register_sets - 1;
+  return m_register_set_count;
 }
 
 size_t RegisterInfoPOSIX_arm64::GetRegisterSetFromRegisterIndex(
     uint32_t reg_index) const {
-  if (reg_index <= gpr_w28)
-    return GPRegSet;
-  if (reg_index <= fpu_fpcr)
-    return FPRegSet;
-  if (reg_index <= sve_ffr)
-    return SVERegSet;
+  for (const auto &regset_range : m_per_regset_regnum_range) {
+    if (reg_index >= regset_range.second.first &&
+        reg_index <= regset_range.second.second)
+      return regset_range.first;
+  }
   return LLDB_INVALID_REGNUM;
 }
 
 const lldb_private::RegisterSet *
 RegisterInfoPOSIX_arm64::GetRegisterSet(size_t set_index) const {
   if (set_index < GetRegisterSetCount())
-    return &g_reg_sets_arm64[set_index];
+    return &m_register_set_p[set_index];
   return nullptr;
 }
 
-uint32_t
-RegisterInfoPOSIX_arm64::ConfigureVectorRegisterInfos(uint32_t sve_vq) {
+void RegisterInfoPOSIX_arm64::ConfigureRegisterInfos(uint32_t opt_regsets) {
+  // TODO: Comment Here
+  if (opt_regsets > ARM64_REGS_CONFIG_SVE) {
+    m_reg_infos_is_dynamic = true;
+  }
+
+  if (m_reg_infos_is_dynamic) {
+    const lldb_private::RegisterInfo *reginfo_start, *reginfo_end;
+    const lldb_private::RegisterSet *regset_start = g_reg_sets_arm64;
+    if (opt_regsets & ARM64_REGS_CONFIG_SVE) {
+      reginfo_start = g_register_infos_arm64_sve_le;
+      reginfo_end = g_register_infos_arm64_sve_le + sve_ffr + 1;
+      m_per_regset_regnum_range[m_register_set_count] =
+          std::make_pair(sve_vg, sve_ffr);
+      m_register_set_count++;
+    } else {
+      reginfo_start = g_register_infos_arm64_le;
+      reginfo_end = g_register_infos_arm64_le + fpu_fpcr + 1;
+    }
+
+    std::copy(reginfo_start, reginfo_end,
+              std::back_inserter(m_dynamic_reg_infos));
+    std::copy(regset_start, regset_start + m_register_set_count,
+              std::back_inserter(m_dynamic_reg_sets));
+
+    m_register_info_count = m_dynamic_reg_infos.size();
+    m_register_info_p = m_dynamic_reg_infos.data();
+    m_register_set_p = m_dynamic_reg_sets.data();
+    m_register_set_count = m_dynamic_reg_sets.size();
+  } else {
+    if (opt_regsets & ARM64_REGS_CONFIG_SVE) {
+      m_register_info_p = g_register_infos_arm64_sve_le;
+      m_register_info_count =
+          static_cast<uint32_t>(sizeof(g_register_infos_arm64_sve_le) /
+                                sizeof(g_register_infos_arm64_sve_le[0]));
+      m_per_regset_regnum_range[m_register_set_count] =
+          std::make_pair(sve_vg, sve_ffr);
+      m_register_set_count++;
+    }
+  }
+}
+
+uint32_t RegisterInfoPOSIX_arm64::ConfigureVectorLength(uint32_t sve_vq) {
   // sve_vq contains SVE Quad vector length in context of AArch64 SVE.
   // SVE register infos if enabled cannot be disabled by selecting sve_vq = 0.
   // Also if an invalid or previously set vector length is passed to this
   // function then it will exit immediately with previously set vector length.
   if (!VectorSizeIsValid(sve_vq) || m_vector_reg_vq == sve_vq)
     return m_vector_reg_vq;
 
   // We cannot enable AArch64 only mode if SVE was enabled.
   if (sve_vq == eVectorQuadwordAArch64 &&
       m_vector_reg_vq > eVectorQuadwordAArch64)
     sve_vq = eVectorQuadwordAArch64SVE;
 
   m_vector_reg_vq = sve_vq;
 
-  if (sve_vq == eVectorQuadwordAArch64) {
-    m_register_info_count =
-        static_cast<uint32_t>(sizeof(g_register_infos_arm64_le) /
-                              sizeof(g_register_infos_arm64_le[0]));
-    m_register_info_p = g_register_infos_arm64_le;
-
+  if (sve_vq == eVectorQuadwordAArch64)
     return m_vector_reg_vq;
-  }
-
-  m_register_info_count =
-      static_cast<uint32_t>(sizeof(g_register_infos_arm64_sve_le) /
-                            sizeof(g_register_infos_arm64_sve_le[0]));
-
   std::vector<lldb_private::RegisterInfo> &reg_info_ref =
       m_per_vq_reg_infos[sve_vq];
 
   if (reg_info_ref.empty()) {
-    reg_info_ref = llvm::makeArrayRef(g_register_infos_arm64_sve_le,
-                                      m_register_info_count);
+    reg_info_ref = llvm::makeArrayRef(m_register_info_p, m_register_info_count);
 
     uint32_t offset = SVE_REGS_DEFAULT_OFFSET_LINUX;
-
     reg_info_ref[fpu_fpsr].byte_offset = offset;
     reg_info_ref[fpu_fpcr].byte_offset = offset + 4;
     reg_info_ref[sve_vg].byte_offset = offset + 8;
     offset += 16;
 
     // Update Z registers size and offset
     uint32_t s_reg_base = fpu_s0;
     uint32_t d_reg_base = fpu_d0;
if (reg_info_ref.empty()) {
 
     // Update P registers and FFR size and offset
     for (uint32_t it = sve_p0; it <= sve_ffr; it++) {
       reg_info_ref[it].byte_offset = offset;
       reg_info_ref[it].byte_size = sve_vq * SVE_QUAD_WORD_BYTES / 8;
       offset += reg_info_ref[it].byte_size;
     }
 
+    for (uint32_t it = sve_ffr + 1; it < m_register_info_count; it++) {
+      reg_info_ref[it].byte_offset = offset;
+      offset += reg_info_ref[it].byte_size;
+    }
+
     m_per_vq_reg_infos[sve_vq] = reg_info_ref;
   }
 
-  m_register_info_p = reg_info_ref.data();
+  m_register_info_p = m_per_vq_reg_infos[sve_vq].data();
   return m_vector_reg_vq;
 }
 
+bool RegisterInfoPOSIX_arm64::IsSVEReg(unsigned reg) const {
+  if (m_vector_reg_vq > eVectorQuadwordAArch64)
+    return (sve_vg <= reg && reg <= sve_ffr);
+  else
+    return false;
+}
+
 bool RegisterInfoPOSIX_arm64::IsSVEZReg(unsigned reg) const {
   return (sve_z0 <= reg && reg <= sve_z31);
 }
 
 bool RegisterInfoPOSIX_arm64::IsSVEPReg(unsigned reg) const {
   return (sve_p0 <= reg && reg <= sve_p15);
 }
 

lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp

uint16_t sve_header_flags_field =
         m_sveregset.GetU16(&sve_header_field_offset);
     if ((sve_header_flags_field & sve::ptrace_regs_mask) ==
         sve::ptrace_regs_fpsimd)
       m_sve_state = SVEState::FPSIMD;
     else if ((sve_header_flags_field & sve::ptrace_regs_mask) ==
              sve::ptrace_regs_sve)
       m_sve_state = SVEState::Full;
 
-    if (sve::vl_valid(m_sve_vector_length))
-      m_register_info_up->ConfigureVectorRegisterInfos(
-          sve::vq_from_vl(m_sve_vector_length));
-    else {
+    if (!sve::vl_valid(m_sve_vector_length)) {
       m_sve_state = SVEState::Disabled;
       m_sve_vector_length = 0;
     }
   } else
     m_sve_state = SVEState::Disabled;
+
+  if (m_sve_state != SVEState::Disabled) {
+    m_register_info_up->ConfigureRegisterInfos(ARM64_REGS_CONFIG_SVE);
+    m_register_info_up->ConfigureVectorLength(
+        sve::vq_from_vl(m_sve_vector_length));
+  }
 }
 
 uint32_t RegisterContextCorePOSIX_arm64::CalculateSVEOffset(
     const RegisterInfo *reg_info) {
   // Start of Z0 data is after GPRs plus 8 bytes of vg register
   uint32_t sve_reg_offset = LLDB_INVALID_INDEX32;
   if (m_sve_state == SVEState::FPSIMD) {
     const uint32_t reg = reg_info->kinds[lldb::eRegisterKindLLDB];