[lldb][AIX] Added RegisterInfo file for PPC64

[HemangGadhavi]

This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:

1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. Extending LLDB to work on AIX #101657
   The complete changes for porting are present in this draft PR:
   Extending LLDB to work on AIX #102601

• Added register information file for PPC64 big-endian architecture (used by AIX)

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Hemang Gadhavi (HemangGadhavi)

Changes

This PR is in reference to porting LLDB on AIX.
Link to discussions on llvm discourse and github:

1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. Extending LLDB to work on AIX #101657
   The complete changes for porting are present in this draft PR:
   Extending LLDB to work on AIX #102601

• Added register information file for PPC64 big-endian architecture (used by AIX)
  @DavidSpickett @labath @DhruvSrivastavaX

---

Full diff: https://github.com/llvm/llvm-project/pull/165367.diff

3 Files Affected:

• (modified) lldb/source/Plugins/Process/Utility/CMakeLists.txt (+1)
• (added) lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.cpp (+61)
• (added) lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.h (+31)

diff --git a/lldb/source/Plugins/Process/Utility/CMakeLists.txt b/lldb/source/Plugins/Process/Utility/CMakeLists.txt
index b1e326ec064e4..997fdbda05839 100644
--- a/lldb/source/Plugins/Process/Utility/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/Utility/CMakeLists.txt
@@ -60,6 +60,7 @@ add_lldb_library(lldbPluginProcessUtility
   RegisterInfoPOSIX_arm64.cpp
   RegisterInfoPOSIX_loongarch64.cpp
   RegisterInfoPOSIX_ppc64le.cpp
+  RegisterInfoPOSIX_ppc64.cpp
   RegisterInfoPOSIX_riscv32.cpp
   RegisterInfoPOSIX_riscv64.cpp
   StopInfoMachException.cpp
diff --git a/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.cpp b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.cpp
new file mode 100644
index 0000000000000..1550f00bea28e
--- /dev/null
+++ b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.cpp
@@ -0,0 +1,61 @@
+//===-- RegisterInfoPOSIX_ppc64.cpp ---------------------------------------===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+
+#include <cassert>
+#include <cstddef>
+#include <vector>
+
+#include "lldb/lldb-defines.h"
+#include "llvm/Support/Compiler.h"
+
+#include "RegisterInfoPOSIX_ppc64.h"
+
+// Include RegisterInfoPOSIX_ppc64 to declare our g_register_infos_ppc64
+#define DECLARE_REGISTER_INFOS_PPC64_STRUCT
+#include "RegisterInfos_ppc64.h"
+#undef DECLARE_REGISTER_INFOS_PPC64_STRUCT
+
+static const lldb_private::RegisterInfo *
+GetRegisterInfoPtr(const lldb_private::ArchSpec &target_arch) {
+  switch (target_arch.GetMachine()) {
+  case llvm::Triple::ppc64:
+    return g_register_infos_ppc64;
+  default:
+    assert(false && "Unhandled target architecture.");
+    return nullptr;
+  }
+}
+
+static uint32_t
+GetRegisterInfoCount(const lldb_private::ArchSpec &target_arch) {
+  switch (target_arch.GetMachine()) {
+  case llvm::Triple::ppc64:
+    return static_cast<uint32_t>(sizeof(g_register_infos_ppc64) /
+                                 sizeof(g_register_infos_ppc64[0]));
+  default:
+    assert(false && "Unhandled target architecture.");
+    return 0;
+  }
+}
+
+RegisterInfoPOSIX_ppc64::RegisterInfoPOSIX_ppc64(
+    const lldb_private::ArchSpec &target_arch)
+    : lldb_private::RegisterInfoInterface(target_arch),
+      m_register_info_p(GetRegisterInfoPtr(target_arch)),
+      m_register_info_count(GetRegisterInfoCount(target_arch)) {}
+
+size_t RegisterInfoPOSIX_ppc64::GetGPRSize() const { return sizeof(GPR_PPC64); }
+
+const lldb_private::RegisterInfo *
+RegisterInfoPOSIX_ppc64::GetRegisterInfo() const {
+  return m_register_info_p;
+}
+
+uint32_t RegisterInfoPOSIX_ppc64::GetRegisterCount() const {
+  return m_register_info_count;
+}
diff --git a/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.h b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.h
new file mode 100644
index 0000000000000..4805883e5b848
--- /dev/null
+++ b/lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_ppc64.h
@@ -0,0 +1,31 @@
+//===-- RegisterInfoPOSIX_ppc64.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_PPC64_H
+#define LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERINFOPOSIX_PPC64_H
+
+#include "RegisterInfoInterface.h"
+#include "lldb/Target/RegisterContext.h"
+#include "lldb/lldb-private.h"
+
+class RegisterInfoPOSIX_ppc64 : public lldb_private::RegisterInfoInterface {
+public:
+  RegisterInfoPOSIX_ppc64(const lldb_private::ArchSpec &target_arch);
+
+  size_t GetGPRSize() const override;
+
+  const lldb_private::RegisterInfo *GetRegisterInfo() const override;
+
+  uint32_t GetRegisterCount() const override;
+
+private:
+  const lldb_private::RegisterInfo *m_register_info_p;
+  uint32_t m_register_info_count;
+};
+
+#endif // #ifndef LLDB_SOURCE_PLUGINS_PROCESS_UTILITY_REGISTERINFOPOSIX_PPC64_H

[DavidSpickett]

I'm looking at the ppc64le file and there's nothing in there that is endian dependent other than the names of some variables. Please check whether it would be possible to rename parts of the existing ppc64le code and re-use it. There'll be some limit to this of course, but I think at least the names and sizes of registers could be reused.

One way to do this would be to actually copy all the things to make ppc(be) versions, until you have something working. Then try merging each part of duplicated code. With the aim of a PR that only duplicates what is needed (or at least you think is needed, we can discuss it of course).

Or you can start doing it from scratch, whatever you have the appetite for.

[HemangGadhavi]

@DavidSpickett
Agreed — the existing ppc64le implementation doesn’t contain much endianness-specific logic. However, reusing and renaming the existing ppc64le code would require several modifications to the current linux_ppc64le implementation, which we’d prefer to keep intact to avoid impacting the existing code path.

Therefore, we decided to develop the PPC big-endian (BE) support from scratch to maintain clear separation.
We also have a plan to add 32-bit support in the future, and this approach will allow us to reuse or consolidate common functionality within shared PPC-BE files for both 64 and 32.

[DavidSpickett]

Ok well in a perhaps counter-intuitive way, I'd be ok with some duplication as long as it's basically identical copies. This makes it easier to divide the "copy for convenience" and the "copy and modify for good reasons".

So I think it comes down to what benefits you get from having separate code. Do you have a branch I could look at and see the subsequent changes so I can get an idea of where you need to diverge? It does not have to be review quality, I just need a rough idea of where you're going with this.

Also if we're going down the duplication path, I think I'd want to see ppc64le and ppc64be naming, instead of just ppc. I know ppc implies be but not to anyone who hasn't worked with it before. Then again maybe seeing your changes will change my mind on that.

[HemangGadhavi]

So I think it comes down to what benefits you get from having separate code. Do you have a branch I could look at and see the subsequent changes so I can get an idea of where you need to diverge? It does not have to be review quality, I just need a rough idea of where you're going with this.

The changes are still under active development, and we haven’t created a dedicated branch for this work yet. The major benefits is to accommodate the architectural differences without modifying existing code path.

Also if we're going down the duplication path, I think I'd want to see ppc64le and ppc64be naming, instead of just ppc. I know ppc implies be but not to anyone who hasn't worked with it before. Then again maybe seeing your changes will change my mind on that.

That makes sense and can be done if needed. However, we’ve been following the LLVM naming convention,(where ppc64le is used for Little Endian and ppc64 implicitly refers to Big Endian).
Renaming files and associated registers/variables identifiers from ppc64 to ppc64be could introduce confusion, since the target architecture is defined as ppc64 while the corresponding file names would use ppc64be. This mismatch might reduce consistency and clarity across the codebase.
What do you think — would it make sense to keep the current LLVM-style naming for consistency, or would explicitly using ppc64be be preferable despite the potential mismatch between the architecture name and file names?

LLVM code snippet for reference.

  /// Tests whether the target is 64-bit PowerPC (little and big endian).       
  bool isPPC64() const {                                                        
    return getArch() == Triple::ppc64 || getArch() == Triple::ppc64le;             
  }  

[DavidSpickett]

The changes are still under active development, and we haven’t created a dedicated branch for this work yet. The major benefits is to accommodate the architectural differences without modifying existing code path.

Ok for now I'll say that if indeed it's better to have 2 distinct code paths, this PR would make sense as is.

I think working on it as a separate code path is a good approach regardless of whether or not some parts get merged when upstreamed. So your efforts will not be wasted.

Let me know when you've got something I can look at.

we’ve been following the LLVM naming convention

In that case ppc64/ppc64le is fine.