[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
https://github.com/DhruvSrivastavaX updated
https://github.com/llvm/llvm-project/pull/116338
>From 0c63800bdcbadcfceed4c9a81305eda7d5a15960 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava
Date: Fri, 15 Nov 2024 02:16:31 -0600
Subject: [PATCH 1/6] Added XCOFF Header Parsing
---
.../ObjectFile/XCOFF/ObjectFileXCOFF.cpp | 126 +-
.../ObjectFile/XCOFF/ObjectFileXCOFF.h| 58
2 files changed, 181 insertions(+), 3 deletions(-)
diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
index 3be900f9a4bc9f..c06ece4347822d 100644
--- a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
@@ -81,9 +81,44 @@ ObjectFile *ObjectFileXCOFF::CreateInstance(const
lldb::ModuleSP &module_sp,
if (!objfile_up)
return nullptr;
+ // Cache xcoff binary.
+ if (!objfile_up->CreateBinary())
+return nullptr;
+
+ if (!objfile_up->ParseHeader())
+return nullptr;
+
return objfile_up.release();
}
+bool ObjectFileXCOFF::CreateBinary() {
+ if (m_binary)
+return true;
+
+ Log *log = GetLog(LLDBLog::Object);
+
+ auto binary = llvm::object::XCOFFObjectFile::createObjectFile(
+ llvm::MemoryBufferRef(toStringRef(m_data.GetData()),
+m_file.GetFilename().GetStringRef()),
+ file_magic::xcoff_object_64);
+ if (!binary) {
+LLDB_LOG_ERROR(log, binary.takeError(),
+ "Failed to create binary for file ({1}): {0}", m_file);
+return false;
+ }
+
+ // Make sure we only handle XCOFF format.
+ m_binary =
+ llvm::unique_dyn_cast(std::move(*binary));
+ if (!m_binary)
+return false;
+
+ LLDB_LOG(log, "this = {0}, module = {1} ({2}), file = {3}, binary = {4}",
+ this, GetModule().get(), GetModule()->GetSpecificationDescription(),
+ m_file.GetPath(), m_binary.get());
+ return true;
+}
+
ObjectFile *ObjectFileXCOFF::CreateMemoryInstance(
const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
@@ -136,13 +171,92 @@ bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP
&data_sp,
return XCOFFHeaderSizeFromMagic(magic) != 0;
}
-bool ObjectFileXCOFF::ParseHeader() { return false; }
+bool ObjectFileXCOFF::ParseHeader() {
+ ModuleSP module_sp(GetModule());
+ if (module_sp) {
+std::lock_guard guard(module_sp->GetMutex());
+lldb::offset_t offset = 0;
+
+if (ParseXCOFFHeader(m_data, &offset, m_xcoff_header)) {
+ m_data.SetAddressByteSize(GetAddressByteSize());
+ if (m_xcoff_header.auxhdrsize > 0)
+ParseXCOFFOptionalHeader(m_data, &offset);
+}
+return true;
+ }
+
+ return false;
+}
+
+bool ObjectFileXCOFF::ParseXCOFFHeader(lldb_private::DataExtractor &data,
+ lldb::offset_t *offset_ptr,
+ xcoff_header_t &xcoff_header) {
+ // FIXME: data.ValidOffsetForDataOfSize
+ xcoff_header.magic = data.GetU16(offset_ptr);
+ xcoff_header.nsects = data.GetU16(offset_ptr);
+ xcoff_header.modtime = data.GetU32(offset_ptr);
+ xcoff_header.symoff = data.GetU64(offset_ptr);
+ xcoff_header.auxhdrsize = data.GetU16(offset_ptr);
+ xcoff_header.flags = data.GetU16(offset_ptr);
+ xcoff_header.nsyms = data.GetU32(offset_ptr);
+ return true;
+}
+
+bool ObjectFileXCOFF::ParseXCOFFOptionalHeader(
+lldb_private::DataExtractor &data, lldb::offset_t *offset_ptr) {
+ lldb::offset_t init_offset = *offset_ptr;
+ // FIXME: data.ValidOffsetForDataOfSize
+ m_xcoff_aux_header.AuxMagic = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.Version = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.ReservedForDebugger = data.GetU32(offset_ptr);
+ m_xcoff_aux_header.TextStartAddr = data.GetU64(offset_ptr);
+ m_xcoff_aux_header.DataStartAddr = data.GetU64(offset_ptr);
+ m_xcoff_aux_header.TOCAnchorAddr = data.GetU64(offset_ptr);
+ m_xcoff_aux_header.SecNumOfEntryPoint = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfText = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfData = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfTOC = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfLoader = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.SecNumOfBSS = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.MaxAlignOfText = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.MaxAlignOfData = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.ModuleType = data.GetU16(offset_ptr);
+ m_xcoff_aux_header.CpuFlag = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.CpuType = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.TextPageSize = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.DataPageSize = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.StackPageSize = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.FlagAndTDataAlignment = data.GetU8(offset_ptr);
+ m_xcoff_aux_header.TextSize = data.GetU64(offset_p
[Lldb-commits] [lldb] [lldb] Improving unit test helpers by utilizing llvm helpers. (PR #119148)
https://github.com/ashgti created
https://github.com/llvm/llvm-project/pull/119148
This was suggested in a previous patch after the commit was already submitted.
>From 4ad591f11b2dec8cf380ecbc02d18a6e6a0101a6 Mon Sep 17 00:00:00 2001
From: John Harrison
Date: Sun, 8 Dec 2024 12:15:14 -0800
Subject: [PATCH] [lldb] Improving unit test helpers by utilitizing llvm
helpers.
This was suggested in a previous patch after the commit was already submitted.
---
.../TestingSupport/Host/SocketTestUtilities.cpp| 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 80545b8c533a03..72ecde845567f7 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -122,10 +122,9 @@ bool lldb_private::HostSupportsLocalhostToIPv4() {
auto addresses = SocketAddress::GetAddressInfo(
"localhost", nullptr, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
- return std::find_if(addresses.begin(), addresses.end(),
- [](SocketAddress &addr) {
-return addr.GetFamily() == AF_INET;
- }) != addresses.end();
+ return llvm::any_of(addresses, [](const SocketAddress &addr) {
+return addr.GetFamily() == AF_INET;
+ });
}
bool lldb_private::HostSupportsLocalhostToIPv6() {
@@ -134,10 +133,9 @@ bool lldb_private::HostSupportsLocalhostToIPv6() {
auto addresses = SocketAddress::GetAddressInfo(
"localhost", nullptr, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
- return std::find_if(addresses.begin(), addresses.end(),
- [](SocketAddress &addr) {
-return addr.GetFamily() == AF_INET6;
- }) != addresses.end();
+ return llvm::any_of(addresses, [](const SocketAddress &addr) {
+return addr.GetFamily() == AF_INET6;
+ });
}
llvm::Expected lldb_private::GetLocalhostIP() {
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improving unit test helpers by utilizing llvm helpers. (PR #119148)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: John Harrison (ashgti)
Changes
This was suggested in a previous patch after the commit was already submitted.
---
Full diff: https://github.com/llvm/llvm-project/pull/119148.diff
1 Files Affected:
- (modified) lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp (+6-8)
``diff
diff --git a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
index 80545b8c533a03..72ecde845567f7 100644
--- a/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/Host/SocketTestUtilities.cpp
@@ -122,10 +122,9 @@ bool lldb_private::HostSupportsLocalhostToIPv4() {
auto addresses = SocketAddress::GetAddressInfo(
"localhost", nullptr, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
- return std::find_if(addresses.begin(), addresses.end(),
- [](SocketAddress &addr) {
-return addr.GetFamily() == AF_INET;
- }) != addresses.end();
+ return llvm::any_of(addresses, [](const SocketAddress &addr) {
+return addr.GetFamily() == AF_INET;
+ });
}
bool lldb_private::HostSupportsLocalhostToIPv6() {
@@ -134,10 +133,9 @@ bool lldb_private::HostSupportsLocalhostToIPv6() {
auto addresses = SocketAddress::GetAddressInfo(
"localhost", nullptr, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP);
- return std::find_if(addresses.begin(), addresses.end(),
- [](SocketAddress &addr) {
-return addr.GetFamily() == AF_INET6;
- }) != addresses.end();
+ return llvm::any_of(addresses, [](const SocketAddress &addr) {
+return addr.GetFamily() == AF_INET6;
+ });
}
llvm::Expected lldb_private::GetLocalhostIP() {
``
https://github.com/llvm/llvm-project/pull/119148
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Improving unit test helpers by utilizing llvm helpers. (PR #119148)
https://github.com/ashgti edited https://github.com/llvm/llvm-project/pull/119148 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] HostInfoAIX Support (PR #117906)
@@ -0,0 +1,213 @@
+//===-- HostInfoAIX.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 "lldb/Host/aix/HostInfoAIX.h"
+#include "lldb/Host/Config.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+
+#include "llvm/Support/Threading.h"
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+using namespace lldb_private;
+
+namespace {
+struct HostInfoAIXFields {
+ llvm::once_flag m_distribution_once_flag;
+ std::string m_distribution_id;
+ llvm::once_flag m_os_version_once_flag;
+ llvm::VersionTuple m_os_version;
+};
+} // namespace
+
+static HostInfoAIXFields *g_fields = nullptr;
+
+void HostInfoAIX::Initialize(SharedLibraryDirectoryHelper *helper) {
+ HostInfoPosix::Initialize(helper);
+
+ g_fields = new HostInfoAIXFields();
+}
+
+void HostInfoAIX::Terminate() {
+ assert(g_fields && "Missing call to Initialize?");
+ delete g_fields;
+ g_fields = nullptr;
+ HostInfoBase::Terminate();
+}
+
+llvm::VersionTuple HostInfoAIX::GetOSVersion() {
+ assert(g_fields && "Missing call to Initialize?");
+ llvm::call_once(g_fields->m_os_version_once_flag, []() {
+struct utsname un;
+if (uname(&un) != 0)
+ return;
+
+llvm::StringRef release = un.release;
+// The kernel release string can include a lot of stuff (e.g.
+// 4.9.0-6-amd64). We're only interested in the numbered prefix.
+release = release.substr(0, release.find_first_not_of("0123456789."));
+g_fields->m_os_version.tryParse(release);
+ });
+
+ return g_fields->m_os_version;
+}
+
+std::optional HostInfoAIX::GetOSBuildString() {
+ struct utsname un;
+ ::memset(&un, 0, sizeof(utsname));
+
+ if (uname(&un) < 0)
+return std::nullopt;
+
+ return std::string(un.release);
+}
+
+llvm::StringRef HostInfoAIX::GetDistributionId() {
DhruvSrivastavaX wrote:
I understand your concern, and I would truly appreciate your guidance as I work
to fill the gaps in my understanding of the flow during these incremental
merges. My goal is the same as yours: to keep the code as efficient and
maintainable as possible while making the process smoother over time, and
please be assured that I will keep all your concerns and suggestions into
account!
https://github.com/llvm/llvm-project/pull/117906
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] HostInfoAIX Support (PR #117906)
@@ -0,0 +1,213 @@
+//===-- HostInfoAIX.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 "lldb/Host/aix/HostInfoAIX.h"
+#include "lldb/Host/Config.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+
+#include "llvm/Support/Threading.h"
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+using namespace lldb_private;
+
+namespace {
+struct HostInfoAIXFields {
+ llvm::once_flag m_distribution_once_flag;
+ std::string m_distribution_id;
+ llvm::once_flag m_os_version_once_flag;
+ llvm::VersionTuple m_os_version;
+};
+} // namespace
+
+static HostInfoAIXFields *g_fields = nullptr;
+
+void HostInfoAIX::Initialize(SharedLibraryDirectoryHelper *helper) {
+ HostInfoPosix::Initialize(helper);
+
+ g_fields = new HostInfoAIXFields();
+}
+
+void HostInfoAIX::Terminate() {
+ assert(g_fields && "Missing call to Initialize?");
+ delete g_fields;
+ g_fields = nullptr;
+ HostInfoBase::Terminate();
+}
+
+llvm::VersionTuple HostInfoAIX::GetOSVersion() {
+ assert(g_fields && "Missing call to Initialize?");
+ llvm::call_once(g_fields->m_os_version_once_flag, []() {
+struct utsname un;
+if (uname(&un) != 0)
+ return;
+
+llvm::StringRef release = un.release;
+// The kernel release string can include a lot of stuff (e.g.
+// 4.9.0-6-amd64). We're only interested in the numbered prefix.
+release = release.substr(0, release.find_first_not_of("0123456789."));
+g_fields->m_os_version.tryParse(release);
+ });
+
+ return g_fields->m_os_version;
+}
+
+std::optional HostInfoAIX::GetOSBuildString() {
+ struct utsname un;
+ ::memset(&un, 0, sizeof(utsname));
+
+ if (uname(&un) < 0)
+return std::nullopt;
+
+ return std::string(un.release);
+}
+
+llvm::StringRef HostInfoAIX::GetDistributionId() {
+ assert(g_fields && "Missing call to Initialize?");
+ // Try to run 'lbs_release -i', and use that response for the distribution
+ // id.
+ llvm::call_once(g_fields->m_distribution_once_flag, []() {
+Log *log = GetLog(LLDBLog::Host);
+LLDB_LOGF(log, "attempting to determine AIX distribution...");
+
+// check if the lsb_release command exists at one of the following paths
+const char *const exe_paths[] = {"/bin/lsb_release",
+ "/usr/bin/lsb_release"};
+
+for (size_t exe_index = 0;
+ exe_index < sizeof(exe_paths) / sizeof(exe_paths[0]); ++exe_index) {
+ const char *const get_distribution_info_exe = exe_paths[exe_index];
+ if (access(get_distribution_info_exe, F_OK)) {
+// this exe doesn't exist, move on to next exe
+LLDB_LOGF(log, "executable doesn't exist: %s",
+ get_distribution_info_exe);
+continue;
+ }
+
+ // execute the distribution-retrieval command, read output
+ std::string get_distribution_id_command(get_distribution_info_exe);
+ get_distribution_id_command += " -i";
+
+ FILE *file = popen(get_distribution_id_command.c_str(), "r");
+ if (!file) {
+LLDB_LOGF(log,
+ "failed to run command: \"%s\", cannot retrieve "
+ "platform information",
+ get_distribution_id_command.c_str());
+break;
+ }
+
+ // retrieve the distribution id string.
+ char distribution_id[256] = {'\0'};
+ if (fgets(distribution_id, sizeof(distribution_id) - 1, file) !=
+ nullptr) {
+LLDB_LOGF(log, "distribution id command returned \"%s\"",
+ distribution_id);
+
+const char *const distributor_id_key = "Distributor ID:\t";
+if (strstr(distribution_id, distributor_id_key)) {
+ // strip newlines
+ std::string id_string(distribution_id + strlen(distributor_id_key));
+ llvm::erase(id_string, '\n');
+
+ // lower case it and convert whitespace to underscores
+ std::transform(
+ id_string.begin(), id_string.end(), id_string.begin(),
+ [](char ch) { return tolower(isspace(ch) ? '_' : ch); });
+
+ g_fields->m_distribution_id = id_string;
+ LLDB_LOGF(log, "distribution id set to \"%s\"",
+g_fields->m_distribution_id.c_str());
+} else {
+ LLDB_LOGF(log, "failed to find \"%s\" field in \"%s\"",
+distributor_id_key, distribution_id);
+}
+ } else {
+LLDB_LOGF(log,
+ "failed to retrieve distribution id, \"%s\" returned no"
+ " lines",
+ get_distribution_id_command.c_str());
+ }
+
+ // clean up the file
+ p
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
DhruvSrivastavaX wrote: > I think we can make some progress here, but I don't think we'll get far > without ProcessLauncher support. At some point, not too far from now, I'm > going to start asking questions like "which tests does this fix", and I don't > think you'll be able to run any of them without a process launcher. Yes, Thats true. I am just adding this as a part of the parallel drops for each of the independent plugins. Will drop ProcessLauncher support too as a separate patch soon. But yes, It would be great to get inputs from you regarding adding the new tests on which I can build on as I proceed. https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
@@ -0,0 +1,248 @@
+//===-- NativeProcessAIX.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 "NativeProcessAIX.h"
+#include "NativeThreadAIX.h"
+#include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "lldb/Host/Host.h"
+#include "lldb/Host/HostProcess.h"
+#include "lldb/Host/ProcessLaunchInfo.h"
+#include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/LLDBAssert.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/State.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/StringExtractor.h"
+#include "llvm/Support/Errno.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/FileSystem.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::process_aix;
+using namespace llvm;
+
+static constexpr unsigned k_ptrace_word_size = sizeof(void *);
+static_assert(sizeof(long) >= k_ptrace_word_size,
+ "Size of long must be larger than ptrace word size");
+
+// Simple helper function to ensure flags are enabled on the given file
+// descriptor.
+static Status EnsureFDFlags(int fd, int flags) {
DhruvSrivastavaX wrote:
Great, thanks!
https://github.com/llvm/llvm-project/pull/118160
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
@@ -0,0 +1,248 @@
+//===-- NativeProcessAIX.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 "NativeProcessAIX.h"
+#include "NativeThreadAIX.h"
+#include "Plugins/Process/POSIX/ProcessPOSIXLog.h"
+#include "lldb/Host/Host.h"
+#include "lldb/Host/HostProcess.h"
+#include "lldb/Host/ProcessLaunchInfo.h"
+#include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/LLDBAssert.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/State.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/StringExtractor.h"
+#include "llvm/Support/Errno.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Support/FileSystem.h"
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace lldb_private::process_aix;
+using namespace llvm;
+
+static constexpr unsigned k_ptrace_word_size = sizeof(void *);
+static_assert(sizeof(long) >= k_ptrace_word_size,
+ "Size of long must be larger than ptrace word size");
+
+// Simple helper function to ensure flags are enabled on the given file
+// descriptor.
+static Status EnsureFDFlags(int fd, int flags) {
+ Status error;
+
+ int status = fcntl(fd, F_GETFL);
+ if (status == -1) {
+error = Status::FromErrno();
+return error;
+ }
+
+ if (fcntl(fd, F_SETFL, status | flags) == -1) {
+error = Status::FromErrno();
+return error;
+ }
+
+ return error;
+}
+
+NativeProcessAIX::Manager::Manager(MainLoop &mainloop)
+: NativeProcessProtocol::Manager(mainloop) {
+ Status status;
+ m_sigchld_handle = mainloop.RegisterSignal(
+ SIGCHLD, [this](MainLoopBase &) { SigchldHandler(); }, status);
+ assert(m_sigchld_handle && status.Success());
+}
+
+// Public Static Methods
+
+llvm::Expected>
+NativeProcessAIX::Manager::Launch(ProcessLaunchInfo &launch_info,
+ NativeDelegate &native_delegate) {
+ Log *log = GetLog(POSIXLog::Process);
+
+ Status status;
+ ::pid_t pid = ProcessLauncherPosixFork()
+.LaunchProcess(launch_info, status)
+.GetProcessId();
+ LLDB_LOG(log, "pid = {0:x}", pid);
+ if (status.Fail()) {
+LLDB_LOG(log, "failed to launch process: {0}", status);
+return status.ToError();
+ }
+
+ // Wait for the child process to trap on its call to execve.
+ int wstatus = 0;
+ ::pid_t wpid = llvm::sys::RetryAfterSignal(-1, ::waitpid, pid, &wstatus, 0);
+ assert(wpid == pid);
+ UNUSED_IF_ASSERT_DISABLED(wpid);
+ if (!WIFSTOPPED(wstatus)) {
+LLDB_LOG(log, "Could not sync with inferior process: wstatus={1}",
+ WaitStatus::Decode(wstatus));
+return llvm::make_error("Could not sync with inferior
process",
+ llvm::inconvertibleErrorCode());
+ }
+ LLDB_LOG(log, "inferior started, now in stopped state");
+
+ ProcessInstanceInfo Info;
+ if (!Host::GetProcessInfo(pid, Info)) {
+return llvm::make_error("Cannot get process architectrue",
+ llvm::inconvertibleErrorCode());
+ }
+
+ // Set the architecture to the exe architecture.
+ LLDB_LOG(log, "pid = {0}, detected architecture {1}", pid,
+ Info.GetArchitecture().GetArchitectureName());
+
+ return std::unique_ptr(new NativeProcessAIX(
+ pid, launch_info.GetPTY().ReleasePrimaryFileDescriptor(),
native_delegate,
+ Info.GetArchitecture(), *this, {pid}));
+}
+
+llvm::Expected>
+NativeProcessAIX::Manager::Attach(
+lldb::pid_t pid, NativeProcessProtocol::NativeDelegate &native_delegate) {
+ Log *log = GetLog(POSIXLog::Process);
+ LLDB_LOG(log, "pid = {0:x}", pid);
+
+ ProcessInstanceInfo Info;
+ if (!Host::GetProcessInfo(pid, Info)) {
+return llvm::make_error("Cannot get process architectrue",
+ llvm::inconvertibleErrorCode());
+ }
+ auto tids_or = NativeProcessAIX::Attach(pid);
+ if (!tids_or)
+return tids_or.takeError();
+
+ return std::unique_ptr(new NativeProcessAIX(
+ pid, -1, native_delegate, Info.GetArchitecture(), *this, *tids_or));
+}
+
+NativeProcessAIX::Extension
+NativeProcessAIX::Manager::GetSupportedExtensions() const {
+ NativeProcessAIX::Extension supported =
+ Extension::multiprocess | Extension::fork | Extension::vfork |
+ Extension::pass_signals | Extension::auxv | Extension::libraries_svr4 |
+ Extension::siginfo_read;
DhruvSrivastavaX wrote:
Sure
https://github.com/llvm/llvm-project/pull/118160
___
lldb-commits mailing list
ll
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
@@ -0,0 +1,248 @@ +//===-- NativeProcessAIX.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 "NativeProcessAIX.h" +#include "NativeThreadAIX.h" DhruvSrivastavaX wrote: I did test everything while pushing, must be a blunder thats still there. Apologies https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
@@ -0,0 +1,130 @@ +//===-- NativeProcessAIX.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 liblldb_NativeProcessAIX_H_ +#define liblldb_NativeProcessAIX_H_ + +#include +#include + +#include "lldb/Host/Debug.h" +#include "lldb/Host/HostThread.h" +#include "lldb/Target/MemoryRegionInfo.h" +#include "lldb/Utility/ArchSpec.h" +#include "lldb/Utility/FileSpec.h" +#include "lldb/lldb-types.h" +#include "llvm/ADT/SmallPtrSet.h" + +#include "NativeThreadAIX.h" +#include "Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h" +#include "lldb/Host/common/NativeProcessProtocol.h" DhruvSrivastavaX wrote: Sure https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
@@ -0,0 +1,130 @@
+//===-- NativeProcessAIX.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 liblldb_NativeProcessAIX_H_
+#define liblldb_NativeProcessAIX_H_
+
+#include
+#include
+
+#include "lldb/Host/Debug.h"
+#include "lldb/Host/HostThread.h"
+#include "lldb/Target/MemoryRegionInfo.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/lldb-types.h"
+#include "llvm/ADT/SmallPtrSet.h"
+
+#include "NativeThreadAIX.h"
+#include "Plugins/Process/Utility/NativeProcessSoftwareSingleStep.h"
+#include "lldb/Host/common/NativeProcessProtocol.h"
+
+namespace lldb_private {
+class Status;
+class Scalar;
+
+namespace process_aix {
+/// \class NativeProcessAIX
+/// Manages communication with the inferior (debugee) process.
+///
+/// Upon construction, this class prepares and launches an inferior process
+/// for debugging.
+///
+/// Changes in the inferior process state are broadcasted.
+class NativeProcessAIX : public NativeProcessProtocol,
+ private NativeProcessSoftwareSingleStep {
DhruvSrivastavaX wrote:
There are some changes later related to simulating single stepping. Will be
discussing as soon in the later commits.
https://github.com/llvm/llvm-project/pull/118160
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
https://github.com/jasonmolenda created https://github.com/llvm/llvm-project/pull/119171 The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the ZA matrix register (SVL*SVL bytes), and the M4 supports SME2, so the ZT0 register (64 bytes). When SSVE/SME are disabled, none of these registers are provided by the kernel - reads and writes of them will fail. Unlike Linux, lldb cannot modify the SVL through a thread_set_state call, or change the processor state's SSVE/SME status. There is also no way for a process to request a lowered SVL size today, so the work that David did to handle VL/SVL changing while stepping through a process is not an issue on Darwin today. But debugserver should be providing everything necessary so we can reuse all of David's work on resizing the register contexts in lldb if it happens in the future. debugbserver sends svl, svcr, and tpidr2 in the expedited registers when a thread stops, if SSVE|SME mode are enabled (if the kernel allows it to read the ARM_SME_STATE register set). While the maximum SVL is 64 bytes on M4, the AArch64 maximum possible SVL is 256; this would give us a 65k ZA register. If debugserver sized all of its register contexts assuming the largest possible SVL, we could easily use 2MB more memory for the register contexts of all threads in a process -- and on iOS et al, processes must run within a small memory allotment and this would push us over that. Much of the work in debugserver was changing the arm64 register context from being a static compile-time array of register sets, to being initialized at runtime if debugserver is running on a machine with SME. The ZA is only created to the machine's actual maximum SVL. The size of the 32 SVE Z registers is less significant so I am statically allocating those to the architecturally largest possible SVL value today. Also, debugserver includes information about registers that share the same part of the register file. e.g. S0 and D0 are the lower parts of the NEON 128-bit V0 register. And when running on an SME machine, v0 is the lower 128 bits of the SVE Z0 register. So the register maps used when defining the VFP registers must differ depending on the runtime state of the cpu. I also changed register reading in debugserver, where formerly when debugserver was asked to read a register, and the thread_get_state read of that register failed, it would return all zero's. This is necessary when constructing a `g` packet that gets all registers - because there is no separation between register bytes, the offsets are fixed. But when we are asking for a single register (e.g. Z0) when not in SSVE/SME mode, this should return an error. This does mean that when you're running on an SME capabable machine, but not in SME mode, and do `register read -a`, lldb will report that 48 SVE registers were unavailable and 5 SME registers were unavailable. But that's only when `-a` is used. The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which is not yet in a release. The test case I wrote is skipped on current OSes. I pilfered the SME register setup from some of David's existing SME test files; there were a few Linux specific details in those tests that they weren't easy to reuse on Darwin. rdar://121608074 >From 2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 Mon Sep 17 00:00:00 2001 From: Jason Molenda Date: Sun, 8 Dec 2024 22:21:22 -0800 Subject: [PATCH] [lldb][debugserver] Read/write SME registers on arm64 The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the Z
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff 74e8a37ff32e599fd40858e0d6c7e531dcbe4e03
2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 --extensions h,cpp,c --
lldb/test/API/macosx/sme-registers/main.c
lldb/tools/debugserver/source/MacOSX/arm64/sme_thread_status.h
lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp
lldb/tools/debugserver/source/DNBDefs.h
lldb/tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.cpp
lldb/tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.h
lldb/tools/debugserver/source/RNBRemote.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/test/API/macosx/sme-registers/main.c
b/lldb/test/API/macosx/sme-registers/main.c
index 00bbb4a555..04f674d35d 100644
--- a/lldb/test/API/macosx/sme-registers/main.c
+++ b/lldb/test/API/macosx/sme-registers/main.c
@@ -1,12 +1,10 @@
/// BUILT with
-/// xcrun -sdk macosx.internal clang -mcpu=apple-m4 -g sme.c -o sme
+/// xcrun -sdk macosx.internal clang -mcpu=apple-m4 -g sme.c -o sme
-
-#include
#include
+#include
#include
-
void write_sve_regs() {
asm volatile("ptrue p0.b\n\t");
asm volatile("ptrue p1.h\n\t");
@@ -78,37 +76,29 @@ void set_za_register(int svl, int value_offset) {
}
}
-static uint16_t
-arm_sme_svl_b(void)
-{
-uint64_t ret = 0;
-asm volatile (
-"rdsvl %[ret], #1"
-: [ret] "=r"(ret)
-);
-return (uint16_t)ret;
+static uint16_t arm_sme_svl_b(void) {
+ uint64_t ret = 0;
+ asm volatile("rdsvl %[ret], #1" : [ret] "=r"(ret));
+ return (uint16_t)ret;
}
-
//
lldb/test/API/commands/register/register/aarch64_sme_z_registers/save_restore/main.c
-void
-arm_sme2_set_zt0() {
+void arm_sme2_set_zt0() {
#define ZTO_LEN (512 / 8)
-uint8_t data[ZTO_LEN];
-for (unsigned i = 0; i < ZTO_LEN; ++i)
- data[i] = i + 0;
+ uint8_t data[ZTO_LEN];
+ for (unsigned i = 0; i < ZTO_LEN; ++i)
+data[i] = i + 0;
-asm volatile("ldr zt0, [%0]" ::"r"(&data));
+ asm volatile("ldr zt0, [%0]" ::"r"(&data));
#undef ZT0_LEN
}
-int main()
-{
+int main() {
printf("Enable SME mode\n");
- asm volatile ("smstart");
-
+ asm volatile("smstart");
+
write_sve_regs();
set_za_register(arm_sme_svl_b(), 4);
@@ -119,5 +109,5 @@ int main()
c += 5;
c += 5;
- asm volatile ("smstop");
+ asm volatile("smstop");
}
diff --git a/lldb/tools/debugserver/source/MacOSX/arm64/sme_thread_status.h
b/lldb/tools/debugserver/source/MacOSX/arm64/sme_thread_status.h
index c4e845a1f9..d8e69ade1f 100644
--- a/lldb/tools/debugserver/source/MacOSX/arm64/sme_thread_status.h
+++ b/lldb/tools/debugserver/source/MacOSX/arm64/sme_thread_status.h
@@ -9,78 +9,69 @@
#if !defined(ARM_SME_STATE)
#define _STRUCT_ARM_SME_STATE struct arm_sme_state
-_STRUCT_ARM_SME_STATE
-{
-uint64_t svcr;
-uint64_t tpidr2_el0;
-uint16_t svl_b;
+_STRUCT_ARM_SME_STATE {
+ uint64_t svcr;
+ uint64_t tpidr2_el0;
+ uint16_t svl_b;
};
#define _STRUCT_ARM_SVE_Z_STATE struct arm_sve_z_state
-_STRUCT_ARM_SVE_Z_STATE
-{
-charz[16][256];
-} __attribute__((aligned(alignof(unsigned int;
+_STRUCT_ARM_SVE_Z_STATE { char z[16][256]; }
+__attribute__((aligned(alignof(unsigned int;
#define _STRUCT_ARM_SVE_P_STATE struct arm_sve_p_state
-_STRUCT_ARM_SVE_P_STATE
-{
-charp[16][256 / 8];
-} __attribute__((aligned(alignof(unsigned int;
+_STRUCT_ARM_SVE_P_STATE { char p[16][256 / 8]; }
+__attribute__((aligned(alignof(unsigned int;
#define _STRUCT_ARM_SME_ZA_STATE struct arm_sme_za_state
-_STRUCT_ARM_SME_ZA_STATE
-{
-charza[4096];
-} __attribute__((aligned(alignof(unsigned int;
+_STRUCT_ARM_SME_ZA_STATE { char za[4096]; }
+__attribute__((aligned(alignof(unsigned int;
#define _STRUCT_ARM_SME2_STATE struct arm_sme2_state
-_STRUCT_ARM_SME2_STATE
-{
-charzt0[64];
-} __attribute__((aligned(alignof(unsigned int;
+_STRUCT_ARM_SME2_STATE { char zt0[64]; }
+__attribute__((aligned(alignof(unsigned int;
-#define ARM_SME_STATE28
-#define ARM_SVE_Z_STATE1 29
-#define ARM_SVE_Z_STATE2 30
-#define ARM_SVE_P_STATE 31
-#define ARM_SME_ZA_STATE132
-#define ARM_SME_ZA_STATE233
-#define ARM_SME_ZA_STATE334
-#define ARM_SME_ZA_STATE435
-#define ARM_SME_ZA_STATE536
-#define ARM_SME_ZA_STATE637
-#define ARM_SME_ZA_STATE738
-#define ARM_SME_ZA_STATE839
-#define ARM_SME_ZA_STATE940
-#define ARM_SME_ZA_STATE10 41
-#define ARM_SME_ZA_STATE11 42
-#define ARM_SME_ZA_STATE12 42
-#define ARM_SME_ZA_STATE13 44
-#define ARM_SME_ZA_STATE14 45
-#define ARM_SME_ZA_STATE15 46
-#define ARM_SME_ZA_STATE16
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
https://github.com/jasonmolenda edited https://github.com/llvm/llvm-project/pull/119171 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
github-actions[bot] wrote: :warning: Python code formatter, darker found issues in your code. :warning: You can test this locally with the following command: ``bash darker --check --diff -r 74e8a37ff32e599fd40858e0d6c7e531dcbe4e03...2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 lldb/test/API/macosx/sme-registers/TestSMERegistersDarwin.py `` View the diff from darker here. ``diff --- TestSMERegistersDarwin.py 2024-12-09 06:24:49.00 + +++ TestSMERegistersDarwin.py 2024-12-09 06:33:39.105122 + @@ -4,11 +4,10 @@ import lldbsuite.test.lldbutil as lldbutil import os class TestSMERegistersDarwin(TestBase): - NO_DEBUG_INFO_TESTCASE = True mydir = TestBase.compute_mydir(__file__) @skipIfRemote @skipUnlessDarwin `` https://github.com/llvm/llvm-project/pull/119171 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
https://github.com/jasonmolenda edited https://github.com/llvm/llvm-project/pull/119171 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
https://github.com/jasonmolenda updated https://github.com/llvm/llvm-project/pull/119171 >From 2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 Mon Sep 17 00:00:00 2001 From: Jason Molenda Date: Sun, 8 Dec 2024 22:21:22 -0800 Subject: [PATCH 1/2] [lldb][debugserver] Read/write SME registers on arm64 The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the ZA matrix register (SVL*SVL bytes), and the M4 supports SME2, so the ZT0 register (64 bytes). When SSVE/SME are disabled, none of these registers are provided by the kernel - reads and writes of them will fail. Unlike Linux, lldb cannot modify the SVL through a thread_set_state call, or change the processor state's SSVE/SME status. There is also no way for a process to request a lowered SVL size today, so the work that David did to handle VL/SVL changing while stepping through a process is not an issue on Darwin today. But debugserver should be providing everything necessary so we can reuse all of David's work on resizing the register contexts in lldb if it happens in the future. debugbserver sends svl, svcr, and tpidr2 in the expedited registers when a thread stops, if SSVE|SME mode are enabled (if the kernel allows it to read the ARM_SME_STATE register set). While the maximum SVL is 64 bytes on M4, the AArch64 maximum possible SVL is 256; this would give us a 65k ZA register. If debugserver sized all of its register contexts assuming the largest possible SVL, we could easily use 2MB more memory for the register contexts of all threads in a process -- and on iOS et al, processes must run within a small memory allotment and this would push us over that. Much of the work in debugserver was changing the arm64 register context from being a static compile-time array of register sets, to being initialized at runtime if debugserver is running on a machine with SME. The ZA is only created to the machine's actual maximum SVL. The size of the 32 SVE Z registers is less significant so I am statically allocating those to the architecturally largest possible SVL value today. Also, debugserver includes information about registers that share the same part of the register file. e.g. S0 and D0 are the lower parts of the NEON 128-bit V0 register. And when running on an SME machine, v0 is the lower 128 bits of the SVE Z0 register. So the register maps used when defining the VFP registers must differ depending on the runtime state of the cpu. I also changed register reading in debugserver, where formerly when debugserver was asked to read a register, and the thread_get_state read of that register failed, it would return all zero's. This is necessary when constructing a `g` packet that gets all registers - because there is no separation between register bytes, the offsets are fixed. But when we are asking for a single register (e.g. Z0) when not in SSVE/SME mode, this should return an error. This does mean that when you're running on an SME capabable machine, but not in SME mode, and do `register read -a`, lldb will report that 48 SVE registers were unavailable and 5 SME registers were unavailable. But that's only when `-a` is used. The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which is not yet in a release. The test case I wrote is skipped on current OSes. I pilfered the SME register setup from some of David's existing SME test files; there were a few Linux specific details in those tests that they weren't easy to reuse on Darwin. rdar://121608074 --- .../AArch64/ArchitectureAArch64.cpp | 19 + lldb/test/API/macosx/sme-registers/Makefile | 5 + .../sme-registers/TestSMERegistersDarwin.py | 164 lldb/test/API/macosx/sme-registers/main.c | 123 +++ lldb/tools/debugserver/source/DNBDefs.h | 25 +- .../source/MacOSX/arm64/DNBArchImplARM64.cpp | 906 ++ .../source/MacOSX/arm64/DNBArchImplARM64.h| 73 +- .../source/MacOSX/arm64/sme_thread_status.h | 86 ++ lldb/tools/debugserver/source/RNBRemote.cpp | 87 +- 9 files changed, 1247 insertions(+), 241 deletions(-) create mode 100644 lldb/test/API/macosx/sme-registers/Makefile create mode 100644 lldb/test/API/macosx/sme-registers/TestSMERegistersDarwin.py create mode 100644 lldb/test/API/macosx/sme-registers
[Lldb-commits] [lldb] [lldb][AIX] Added base files for NativeProcess Support for AIX (PR #118160)
https://github.com/DhruvSrivastavaX edited https://github.com/llvm/llvm-project/pull/118160 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
jasonmolenda wrote: One difference from debugserver and lldb-server is that lldb-server provides "vg" and "svg" registers (vector granule, streaming vector granule, depending on Streaming mode) which is the vector length in 8-byte granules. On Darwin, debugserver provides only "svl", in bytes. I considered having debugserver report the vector length in granules to match the Linux behavior, but the kernel was giving me the value in bytes and I think it's a more natural representation, so I stuck with it. https://github.com/llvm/llvm-project/pull/119171 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Jason Molenda (jasonmolenda) Changes The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the ZA matrix register (SVL*SVL bytes), and the M4 supports SME2, so the ZT0 register (64 bytes). When SSVE/SME are disabled, none of these registers are provided by the kernel - reads and writes of them will fail. Unlike Linux, lldb cannot modify the SVL through a thread_set_state call, or change the processor state's SSVE/SME status. There is also no way for a process to request a lowered SVL size today, so the work that David did to handle VL/SVL changing while stepping through a process is not an issue on Darwin today. But debugserver should be providing everything necessary so we can reuse all of David's work on resizing the register contexts in lldb if it happens in the future. debugbserver sends svl, svcr, and tpidr2 in the expedited registers when a thread stops, if SSVE|SME mode are enabled (if the kernel allows it to read the ARM_SME_STATE register set). While the maximum SVL is 64 bytes on M4, the AArch64 maximum possible SVL is 256; this would give us a 65k ZA register. If debugserver sized all of its register contexts assuming the largest possible SVL, we could easily use 2MB more memory for the register contexts of all threads in a process -- and on iOS et al, processes must run within a small memory allotment and this would push us over that. Much of the work in debugserver was changing the arm64 register context from being a static compile-time array of register sets, to being initialized at runtime if debugserver is running on a machine with SME. The ZA is only created to the machine's actual maximum SVL. The size of the 32 SVE Z registers is less significant so I am statically allocating those to the architecturally largest possible SVL value today. Also, debugserver includes information about registers that share the same part of the register file. e.g. S0 and D0 are the lower parts of the NEON 128-bit V0 register. And when running on an SME machine, v0 is the lower 128 bits of the SVE Z0 register. So the register maps used when defining the VFP registers must differ depending on the runtime state of the cpu. I also changed register reading in debugserver, where formerly when debugserver was asked to read a register, and the thread_get_state read of that register failed, it would return all zero's. This is necessary when constructing a `g` packet that gets all registers - because there is no separation between register bytes, the offsets are fixed. But when we are asking for a single register (e.g. Z0) when not in SSVE/SME mode, this should return an error. This does mean that when you're running on an SME capabable machine, but not in SME mode, and do `register read -a`, lldb will report that 48 SVE registers were unavailable and 5 SME registers were unavailable. But that's only when `-a` is used. The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which is not yet in a release. The test case I wrote is skipped on current OSes. I pilfered the SME register setup from some of David's existing SME test files; there were a few Linux specific details in those tests that they weren't easy to reuse on Darwin. rdar://121608074 --- Patch is 67.81 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/119171.diff 9 Files Affected: - (modified) lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp (+19) - (added) lldb/test/API/macosx/sme-registers/Makefile (+5) - (added) lldb/test/API/macosx/sme-registers/TestSMERegistersDarwin.py (+164) - (added) lldb/test/API/macosx/sme-registers/main.c (+123) - (modified) lldb/tools/debugserver/source/DNBDefs.h (+15-10) - (modified) lldb/tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.cpp (+720-186) - (modified) lldb/tools/debugserver/source/MacOSX/arm64/DNBArchImplARM64.h (+66-7) - (added) lldb/tools/debugserver/source/MacOSX/arm64/sme_thread_status.h (+86) - (modified) lldb/tools/debugserver/source/RNBRemote.cpp (+49-38) ``diff diff --git a/lldb/source/Plugins/Architecture/AArch64/ArchitectureAArch64.cpp b/lldb/source/Plugins/Arc
[Lldb-commits] [lldb] [lldb][debugserver] Read/write SME registers on arm64 (PR #119171)
https://github.com/jasonmolenda updated https://github.com/llvm/llvm-project/pull/119171 >From 2e3738eb7ed356fe4f9ee24a31af55a01b18bd08 Mon Sep 17 00:00:00 2001 From: Jason Molenda Date: Sun, 8 Dec 2024 22:21:22 -0800 Subject: [PATCH 1/3] [lldb][debugserver] Read/write SME registers on arm64 The Apple M4 line of cores includes the Scalable Matrix Extension (SME) feature. The M4s do not implement Scalable Vector Extension (SVE), although the processor is in Streaming SVE Mode when the SME is being used. The most obvious side effects of being in SSVE Mode are that (on the M4 cores) NEON instructions cannot be used, and watchpoints may get false positives, the address comparisons are done at a lowered granularity. When SSVE mode is enabled, the kernel will provide the Streaming Vector Length register, which is a maximum of 64 bytes with the M4. Also provided are SVCR (with bits indicating if SSVE mode and SME mode are enabled), TPIDR2, SVL. Then the SVE registers Z0..31 (SVL bytes long), P0..15 (SVL/8 bytes), the ZA matrix register (SVL*SVL bytes), and the M4 supports SME2, so the ZT0 register (64 bytes). When SSVE/SME are disabled, none of these registers are provided by the kernel - reads and writes of them will fail. Unlike Linux, lldb cannot modify the SVL through a thread_set_state call, or change the processor state's SSVE/SME status. There is also no way for a process to request a lowered SVL size today, so the work that David did to handle VL/SVL changing while stepping through a process is not an issue on Darwin today. But debugserver should be providing everything necessary so we can reuse all of David's work on resizing the register contexts in lldb if it happens in the future. debugbserver sends svl, svcr, and tpidr2 in the expedited registers when a thread stops, if SSVE|SME mode are enabled (if the kernel allows it to read the ARM_SME_STATE register set). While the maximum SVL is 64 bytes on M4, the AArch64 maximum possible SVL is 256; this would give us a 65k ZA register. If debugserver sized all of its register contexts assuming the largest possible SVL, we could easily use 2MB more memory for the register contexts of all threads in a process -- and on iOS et al, processes must run within a small memory allotment and this would push us over that. Much of the work in debugserver was changing the arm64 register context from being a static compile-time array of register sets, to being initialized at runtime if debugserver is running on a machine with SME. The ZA is only created to the machine's actual maximum SVL. The size of the 32 SVE Z registers is less significant so I am statically allocating those to the architecturally largest possible SVL value today. Also, debugserver includes information about registers that share the same part of the register file. e.g. S0 and D0 are the lower parts of the NEON 128-bit V0 register. And when running on an SME machine, v0 is the lower 128 bits of the SVE Z0 register. So the register maps used when defining the VFP registers must differ depending on the runtime state of the cpu. I also changed register reading in debugserver, where formerly when debugserver was asked to read a register, and the thread_get_state read of that register failed, it would return all zero's. This is necessary when constructing a `g` packet that gets all registers - because there is no separation between register bytes, the offsets are fixed. But when we are asking for a single register (e.g. Z0) when not in SSVE/SME mode, this should return an error. This does mean that when you're running on an SME capabable machine, but not in SME mode, and do `register read -a`, lldb will report that 48 SVE registers were unavailable and 5 SME registers were unavailable. But that's only when `-a` is used. The register reading and writing depends on new register flavor support in thread_get_state/thread_set_state in the kernel, which is not yet in a release. The test case I wrote is skipped on current OSes. I pilfered the SME register setup from some of David's existing SME test files; there were a few Linux specific details in those tests that they weren't easy to reuse on Darwin. rdar://121608074 --- .../AArch64/ArchitectureAArch64.cpp | 19 + lldb/test/API/macosx/sme-registers/Makefile | 5 + .../sme-registers/TestSMERegistersDarwin.py | 164 lldb/test/API/macosx/sme-registers/main.c | 123 +++ lldb/tools/debugserver/source/DNBDefs.h | 25 +- .../source/MacOSX/arm64/DNBArchImplARM64.cpp | 906 ++ .../source/MacOSX/arm64/DNBArchImplARM64.h| 73 +- .../source/MacOSX/arm64/sme_thread_status.h | 86 ++ lldb/tools/debugserver/source/RNBRemote.cpp | 87 +- 9 files changed, 1247 insertions(+), 241 deletions(-) create mode 100644 lldb/test/API/macosx/sme-registers/Makefile create mode 100644 lldb/test/API/macosx/sme-registers/TestSMERegistersDarwin.py create mode 100644 lldb/test/API/macosx/sme-registers
[Lldb-commits] [lldb] Bugfix: Not showing the synthetic children of values behind pointers (PR #117755)
skuznetsov wrote: @clayborg Thank you, Greg! Lots of that info is not described anywhere, no wonder I missed it. Let me try your fixes in my provider, and I will get back to you. By some reason my provider works in CLI lldb, but not in lldb-dap, but I will check if your suggestions will help to fix that. https://github.com/llvm/llvm-project/pull/117755 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AIX] Header Parsing for XCOFF Object File in AIX (PR #116338)
DhruvSrivastavaX wrote: Yes, I did try a few things while rewriting but i was seeing some stray values which were not actually present in the raw file. So just want to make sure that I am using it correctly. https://github.com/llvm/llvm-project/pull/116338 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
