[Lldb-commits] [clang] [lldb] [llvm] [APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) (PR #80309)

2024-10-17 Thread LLVM Continuous Integration via lldb-commits

llvm-ci wrote:

LLVM Buildbot has detected a new failure on builder `openmp-s390x-linux` 
running on `systemz-1` while building `clang,lldb,llvm` at step 6 "test-openmp".

Full details are available at: 
https://lab.llvm.org/buildbot/#/builders/88/builds/3573


Here is the relevant piece of the build log for the reference

```
Step 6 (test-openmp) failure: test (failure)
 TEST 'libomp :: tasking/issue-94260-2.c' FAILED 

Exit Code: -11

Command Output (stdout):
--
# RUN: at line 1
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./bin/clang 
-fopenmp   -I 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src
 -I 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test 
-L 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src
  -fno-omit-frame-pointer -mbackchain -I 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/ompt
 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/tasking/issue-94260-2.c
 -o 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
 -lm -latomic && 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
# executed command: 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./bin/clang 
-fopenmp -I 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src
 -I 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test 
-L 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src
 -fno-omit-frame-pointer -mbackchain -I 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/ompt
 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/tasking/issue-94260-2.c
 -o 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
 -lm -latomic
# executed command: 
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
# note: command had no output on stdout or stderr
# error: command failed with exit status: -11

--




```



https://github.com/llvm/llvm-project/pull/80309
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x0"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x0"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x0"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x0"
+values["r7"] = "0x0"
+values["r8"] = "0x0"
+values["r9"] = "0x0"
+values["r10"] = "0x0"
+values["r11"] = "0x00dd"
+values["r12"] = "0x0"
+values["r13"] = "0x002f"
+values["r14"] = "0x0"
+values["r15"] = "0x0"
+values["r16"] = "0x0"
+values["r17"] = "0x0"
+values["r18"] = "0x0"
+values["r19"] = "0x0"
+values["r20"] = "0x0"
+values["r21"] = "0x0"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x0"
+values["r24"] = "0x0"
+values["r25"] = "0x0"
+values["r26"] = "0x0"
+values["r27"] = "0x0"
+values["r28"] = "0x0"
+values["r29"] = "0x0"
+values["r30"] = "0x0"
+values["r31"] = "0x0"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x0"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x0"

SixWeining wrote:

Should it be `0x00`? Otherwise `0x01` can also match the expect.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x0"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x0"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x0"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x0"
+values["r7"] = "0x0"
+values["r8"] = "0x0"
+values["r9"] = "0x0"
+values["r10"] = "0x0"
+values["r11"] = "0x00dd"
+values["r12"] = "0x0"
+values["r13"] = "0x002f"
+values["r14"] = "0x0"

SixWeining wrote:

Should we use full encoding (i.e. 8bytes)?

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x0"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x0"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x0"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x0"
+values["r7"] = "0x0"
+values["r8"] = "0x0"
+values["r9"] = "0x0"
+values["r10"] = "0x0"
+values["r11"] = "0x00dd"
+values["r12"] = "0x0"
+values["r13"] = "0x002f"
+values["r14"] = "0x0"
+values["r15"] = "0x0"
+values["r16"] = "0x0"
+values["r17"] = "0x0"
+values["r18"] = "0x0"
+values["r19"] = "0x0"
+values["r20"] = "0x0"
+values["r21"] = "0x0"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x0"
+values["r24"] = "0x0"
+values["r25"] = "0x0"
+values["r26"] = "0x0"
+values["r27"] = "0x0"
+values["r28"] = "0x0"
+values["r29"] = "0x0"
+values["r30"] = "0x0"
+values["r31"] = "0x0"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x0"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x0"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x0"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x0"

SixWeining wrote:

0x

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x0"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x0"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x0"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x0"
+values["r7"] = "0x0"
+values["r8"] = "0x0"
+values["r9"] = "0x0"
+values["r10"] = "0x0"
+values["r11"] = "0x00dd"
+values["r12"] = "0x0"
+values["r13"] = "0x002f"
+values["r14"] = "0x0"
+values["r15"] = "0x0"
+values["r16"] = "0x0"
+values["r17"] = "0x0"
+values["r18"] = "0x0"
+values["r19"] = "0x0"
+values["r20"] = "0x0"
+values["r21"] = "0x0"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x0"
+values["r24"] = "0x0"
+values["r25"] = "0x0"
+values["r26"] = "0x0"
+values["r27"] = "0x0"
+values["r28"] = "0x0"
+values["r29"] = "0x0"
+values["r30"] = "0x0"
+values["r31"] = "0x0"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x0"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x0"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x0"

SixWeining wrote:

Ditto.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits


@@ -0,0 +1,84 @@
+//===-- RegisterContextPOSIXCore_loongarch64.cpp 
--===//

SixWeining wrote:

Generally one line has 80 characters at most.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix write only file action to truncate the file (PR #112657)

2024-10-17 Thread David Spickett via lldb-commits

DavidSpickett wrote:

What you describe makes some sense, but could you give an example of where this 
is used?

Can this be triggered with `lldb program file --`? If so 
it would be good to 1. put that in the commit message in case anyone hits the 
same problem and searches the log, and 2. add a release note.

https://github.com/llvm/llvm-project/pull/112657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits

https://github.com/lawn123 updated 
https://github.com/llvm/llvm-project/pull/112296

>From ba485de763a08f6ff3c7468c1a1bfbbfb25ac48f Mon Sep 17 00:00:00 2001
From: Liu An 
Date: Tue, 15 Oct 2024 10:31:35 +0800
Subject: [PATCH 1/2] [LoongArch64]: Add support for LoongArch64 in elf-core
 for lldb

---
 .../Plugins/Process/elf-core/CMakeLists.txt   |  1 +
 .../RegisterContextPOSIXCore_loongarch64.cpp  | 87 +++
 .../RegisterContextPOSIXCore_loongarch64.h| 62 +
 .../Process/elf-core/ThreadElfCore.cpp|  6 ++
 4 files changed, 156 insertions(+)
 create mode 100644 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
 create mode 100644 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h

diff --git a/lldb/source/Plugins/Process/elf-core/CMakeLists.txt 
b/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
index 72925c835b5c89..7473fa8d41ccb3 100644
--- a/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
@@ -10,6 +10,7 @@ add_lldb_library(lldbPluginProcessElfCore PLUGIN
   RegisterContextPOSIXCore_s390x.cpp
   RegisterContextPOSIXCore_x86_64.cpp
   RegisterContextPOSIXCore_riscv64.cpp
+  RegisterContextPOSIXCore_loongarch64.cpp
   RegisterUtilities.cpp
 
   LINK_LIBS
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
new file mode 100644
index 00..af192ecbe01e1b
--- /dev/null
+++ 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
@@ -0,0 +1,87 @@
+//===-- RegisterContextPOSIXCore_loongarch64.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 "RegisterContextPOSIXCore_loongarch64.h"
+
+#include "lldb/Utility/DataBufferHeap.h"
+
+using namespace lldb_private;
+
+std::unique_ptr
+RegisterContextCorePOSIX_loongarch64::Create(Thread &thread,
+ const ArchSpec &arch,
+ const DataExtractor &gpregset,
+ llvm::ArrayRef notes) {
+  return std::unique_ptr(
+  new RegisterContextCorePOSIX_loongarch64(
+  thread,
+  std::make_unique(arch, Flags()),
+  gpregset, notes));
+}
+
+RegisterContextCorePOSIX_loongarch64::RegisterContextCorePOSIX_loongarch64(
+Thread &thread,
+std::unique_ptr register_info,
+const DataExtractor &gpregset, llvm::ArrayRef notes)
+: RegisterContextPOSIX_loongarch64(thread, std::move(register_info)) {
+
+  m_gpr_buffer = std::make_shared(gpregset.GetDataStart(),
+  gpregset.GetByteSize());
+  m_gpr.SetData(m_gpr_buffer);
+  m_gpr.SetByteOrder(gpregset.GetByteOrder());
+
+  ArchSpec arch = m_register_info_up->GetTargetArchitecture();
+  DataExtractor fpregset = getRegset(notes, arch.GetTriple(), FPR_Desc);
+  m_fpr_buffer = std::make_shared(fpregset.GetDataStart(),
+  fpregset.GetByteSize());
+  m_fpr.SetData(m_fpr_buffer);
+  m_fpr.SetByteOrder(fpregset.GetByteOrder());
+}
+
+RegisterContextCorePOSIX_loongarch64::~RegisterContextCorePOSIX_loongarch64() =
+default;
+
+bool RegisterContextCorePOSIX_loongarch64::ReadGPR() { return true; }
+
+bool RegisterContextCorePOSIX_loongarch64::ReadFPR() { return true; }
+
+bool RegisterContextCorePOSIX_loongarch64::WriteGPR() {
+  assert(false && "Writing registers is not allowed for core dumps");
+  return false;
+}
+
+bool RegisterContextCorePOSIX_loongarch64::WriteFPR() {
+  assert(false && "Writing registers is not allowed for core dumps");
+  return false;
+}
+
+bool RegisterContextCorePOSIX_loongarch64::ReadRegister(
+const RegisterInfo *reg_info, RegisterValue &value) {
+  const uint8_t *src = nullptr;
+  lldb::offset_t offset = reg_info->byte_offset;
+
+  if (IsGPR(reg_info->kinds[lldb::eRegisterKindLLDB])) {
+src = m_gpr.GetDataStart();
+  } else if (IsFPR(reg_info->kinds[lldb::eRegisterKindLLDB])) {
+src = m_fpr.GetDataStart();
+offset -= GetGPRSize();
+  } else {
+return false;
+  }
+
+  Status error;
+  value.SetFromMemoryData(*reg_info, src + offset, reg_info->byte_size,
+  lldb::eByteOrderLittle, error);
+  return error.Success();
+}
+
+bool RegisterContextCorePOSIX_loongarch64::WriteRegister(
+const RegisterInfo *reg_info, const RegisterValue &value) {
+  return false;
+}
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch6

[Lldb-commits] [lldb] [lldb][test] Add test for ASTImporter's name conflict resolution (PR #112566)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath commented:

I think this is one of those tests that should really be an API test. As far as 
I can tell, there's nothing darwin-specific about this bug -- except for the 
fact that building shared libraries in a cross-platform manner is hard. But the 
API tests have wrappers that let us do that, and they even support windows. (I 
had a feeling our docs already stated that shared libraries is a reason to make 
something an API test, but I can't find that now.)

I understand the desire to not skip a test (and that making it an API test will 
make that even harder, as a crash will bring down the entire test), but I'm not 
sure if that's so useful as to override this. I also think that making a test 
which checks that something fails in a particular way can be fragile (as a 
random refactor could make it fail in a different way).

That said, thank you for reducing this. Having this around somewhere will be 
very useful for fixing this (eventually). From the looks of things, it may be 
possible to get rid of the dlopen/dlsym thing as well (replace it with hard 
shared library dependencies) -- it seems the important part is that the two 
modules have different definitions of one type, and the way that the shared 
library is loaded is beside the point.

https://github.com/llvm/llvm-project/pull/112566
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread David Spickett via lldb-commits

DavidSpickett wrote:

> @DavidSpickett General debugging commands can be used on LoongArch with some 
> known issues to be addressed. Here is a summary 
> https://github.com/llvm/llvm-project/issues/109394.

For RISC-V I have been using https://github.com/llvm/llvm-project/issues/55383 
as the tracking issue for overall support. If you want to, you could open a 
similar issue and write out what currently works, and I'll link to it from the 
[main lldb page](https://lldb.llvm.org/#platform-support). Not a requirement, 
just if you have the time.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread via lldb-commits

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 7215d5068d96255d487c06d67ae60ba0c04dd08a 
2cce5e77082965f6ef2ab71cfd3aea7d45e953b7 --extensions h,cpp -- 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h 
lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_loongarch64.cpp 
lldb/source/Plugins/Process/elf-core/ThreadElfCore.cpp
``





View the diff from clang-format here.


``diff
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
index b6057b6625..f0500948a6 100644
--- 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
+++ 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
@@ -31,13 +31,13 @@ 
RegisterContextCorePOSIX_loongarch64::RegisterContextCorePOSIX_loongarch64(
 : RegisterContextPOSIX_loongarch64(thread, std::move(register_info)) {
 
   m_gpr.SetData(std::make_shared(gpregset.GetDataStart(),
-  gpregset.GetByteSize()));
+ gpregset.GetByteSize()));
   m_gpr.SetByteOrder(gpregset.GetByteOrder());
 
   ArchSpec arch = m_register_info_up->GetTargetArchitecture();
   DataExtractor fpregset = getRegset(notes, arch.GetTriple(), FPR_Desc);
   m_fpr.SetData(std::make_shared(fpregset.GetDataStart(),
-  fpregset.GetByteSize()));
+ fpregset.GetByteSize()));
   m_fpr.SetByteOrder(fpregset.GetByteOrder());
 }
 
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h
index 80d9218e80..3491f3da87 100644
--- 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h
+++ 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h
@@ -1,4 +1,5 @@
-//===-- RegisterContextPOSIXCore_loongarch64.h --*- C++ 
-*-===//
+//===-- RegisterContextPOSIXCore_loongarch64.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.
@@ -19,7 +20,8 @@
 
 #include 
 
-class RegisterContextCorePOSIX_loongarch64 : public 
RegisterContextPOSIX_loongarch64 {
+class RegisterContextCorePOSIX_loongarch64
+: public RegisterContextPOSIX_loongarch64 {
 public:
   static std::unique_ptr
   Create(lldb_private::Thread &thread, const lldb_private::ArchSpec &arch,

``




https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread via lldb-commits

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 
7215d5068d96255d487c06d67ae60ba0c04dd08a...2cce5e77082965f6ef2ab71cfd3aea7d45e953b7
 lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
``





View the diff from darker here.


``diff
--- TestLinuxCore.py2024-10-17 09:49:05.00 +
+++ TestLinuxCore.py2024-10-17 10:17:17.637355 +
@@ -943,11 +943,10 @@
 substrs=["{} = {}".format(regname, value)],
 )
 
 self.expect("register read --all")
 
-
 def test_get_core_file_api(self):
 """
 Test SBProcess::GetCoreFile() API can successfully get the core file.
 """
 core_file_name = "linux-x86_64.core"

``




https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread David Spickett via lldb-commits




DavidSpickett wrote:

You may be able to reduce the file by changing the `/proc/pid/coredump_filter` 
value: https://man7.org/linux/man-pages/man5/core.5.html

I can't say I understand them all but usually what I do is cut things until the 
test fails. I've been able to get Arm files down to around 20kb doing things, 
but you don't have to take that as a target.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits

https://github.com/lawn123 updated 
https://github.com/llvm/llvm-project/pull/112296

>From ba485de763a08f6ff3c7468c1a1bfbbfb25ac48f Mon Sep 17 00:00:00 2001
From: Liu An 
Date: Tue, 15 Oct 2024 10:31:35 +0800
Subject: [PATCH 1/3] [LoongArch64]: Add support for LoongArch64 in elf-core
 for lldb

---
 .../Plugins/Process/elf-core/CMakeLists.txt   |  1 +
 .../RegisterContextPOSIXCore_loongarch64.cpp  | 87 +++
 .../RegisterContextPOSIXCore_loongarch64.h| 62 +
 .../Process/elf-core/ThreadElfCore.cpp|  6 ++
 4 files changed, 156 insertions(+)
 create mode 100644 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
 create mode 100644 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h

diff --git a/lldb/source/Plugins/Process/elf-core/CMakeLists.txt 
b/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
index 72925c835b5c89..7473fa8d41ccb3 100644
--- a/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
@@ -10,6 +10,7 @@ add_lldb_library(lldbPluginProcessElfCore PLUGIN
   RegisterContextPOSIXCore_s390x.cpp
   RegisterContextPOSIXCore_x86_64.cpp
   RegisterContextPOSIXCore_riscv64.cpp
+  RegisterContextPOSIXCore_loongarch64.cpp
   RegisterUtilities.cpp
 
   LINK_LIBS
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
new file mode 100644
index 00..af192ecbe01e1b
--- /dev/null
+++ 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
@@ -0,0 +1,87 @@
+//===-- RegisterContextPOSIXCore_loongarch64.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 "RegisterContextPOSIXCore_loongarch64.h"
+
+#include "lldb/Utility/DataBufferHeap.h"
+
+using namespace lldb_private;
+
+std::unique_ptr
+RegisterContextCorePOSIX_loongarch64::Create(Thread &thread,
+ const ArchSpec &arch,
+ const DataExtractor &gpregset,
+ llvm::ArrayRef notes) {
+  return std::unique_ptr(
+  new RegisterContextCorePOSIX_loongarch64(
+  thread,
+  std::make_unique(arch, Flags()),
+  gpregset, notes));
+}
+
+RegisterContextCorePOSIX_loongarch64::RegisterContextCorePOSIX_loongarch64(
+Thread &thread,
+std::unique_ptr register_info,
+const DataExtractor &gpregset, llvm::ArrayRef notes)
+: RegisterContextPOSIX_loongarch64(thread, std::move(register_info)) {
+
+  m_gpr_buffer = std::make_shared(gpregset.GetDataStart(),
+  gpregset.GetByteSize());
+  m_gpr.SetData(m_gpr_buffer);
+  m_gpr.SetByteOrder(gpregset.GetByteOrder());
+
+  ArchSpec arch = m_register_info_up->GetTargetArchitecture();
+  DataExtractor fpregset = getRegset(notes, arch.GetTriple(), FPR_Desc);
+  m_fpr_buffer = std::make_shared(fpregset.GetDataStart(),
+  fpregset.GetByteSize());
+  m_fpr.SetData(m_fpr_buffer);
+  m_fpr.SetByteOrder(fpregset.GetByteOrder());
+}
+
+RegisterContextCorePOSIX_loongarch64::~RegisterContextCorePOSIX_loongarch64() =
+default;
+
+bool RegisterContextCorePOSIX_loongarch64::ReadGPR() { return true; }
+
+bool RegisterContextCorePOSIX_loongarch64::ReadFPR() { return true; }
+
+bool RegisterContextCorePOSIX_loongarch64::WriteGPR() {
+  assert(false && "Writing registers is not allowed for core dumps");
+  return false;
+}
+
+bool RegisterContextCorePOSIX_loongarch64::WriteFPR() {
+  assert(false && "Writing registers is not allowed for core dumps");
+  return false;
+}
+
+bool RegisterContextCorePOSIX_loongarch64::ReadRegister(
+const RegisterInfo *reg_info, RegisterValue &value) {
+  const uint8_t *src = nullptr;
+  lldb::offset_t offset = reg_info->byte_offset;
+
+  if (IsGPR(reg_info->kinds[lldb::eRegisterKindLLDB])) {
+src = m_gpr.GetDataStart();
+  } else if (IsFPR(reg_info->kinds[lldb::eRegisterKindLLDB])) {
+src = m_fpr.GetDataStart();
+offset -= GetGPRSize();
+  } else {
+return false;
+  }
+
+  Status error;
+  value.SetFromMemoryData(*reg_info, src + offset, reg_info->byte_size,
+  lldb::eByteOrderLittle, error);
+  return error.Success();
+}
+
+bool RegisterContextCorePOSIX_loongarch64::WriteRegister(
+const RegisterInfo *reg_info, const RegisterValue &value) {
+  return false;
+}
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch6

[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x0"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x0"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x0"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x0"
+values["r7"] = "0x0"
+values["r8"] = "0x0"
+values["r9"] = "0x0"
+values["r10"] = "0x0"
+values["r11"] = "0x00dd"
+values["r12"] = "0x0"
+values["r13"] = "0x002f"
+values["r14"] = "0x0"
+values["r15"] = "0x0"
+values["r16"] = "0x0"
+values["r17"] = "0x0"
+values["r18"] = "0x0"
+values["r19"] = "0x0"
+values["r20"] = "0x0"
+values["r21"] = "0x0"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x0"
+values["r24"] = "0x0"
+values["r25"] = "0x0"
+values["r26"] = "0x0"
+values["r27"] = "0x0"
+values["r28"] = "0x0"
+values["r29"] = "0x0"
+values["r30"] = "0x0"
+values["r31"] = "0x0"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x0"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x0"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x0"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x0"

lawn123 wrote:

> 0x

Other formatting issues have been corrected. Here, only 0x01 and 0x00 are 
allowed. Otherwise, the test will not pass

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread David Spickett via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

DavidSpickett wrote:

Are these 8 bit registers?

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread David Spickett via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")

DavidSpickett wrote:

Is LoongArch one LLVM target or do you need to specifically have LoongArch64 
for this?

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

SixWeining wrote:

Not like fcc registers, fcsr is 32bit.
```
(lldb) register read fcsr
fcsr = 0x
```

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread David Spickett via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only

DavidSpickett wrote:

Maybe this is a terminology difference. To me GP register would mean "general 
purpose" and not include floating point registers. But perhaps you always have 
an FPU so they are kinda general in that they always exist.

I'd just change it to "GP and FP registers" to prevent any confusion.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits

lawn123 wrote:

> I don't see any tests yet, I think 
> `lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py` will be 
> the place for those. There is a template program file you can use in that 
> folder.
@DavidSpickett @SixWeining  I have added two test cases to `TestLinuxCore. py` 
and modified the format as well as the issue with `GetRegisterSetCount`

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits

SixWeining wrote:

> I'm not aware of the current status of LoongArch in LLDB

@DavidSpickett General debugging commands can be used on LoongArch with some 
known issues to be addressed. Here is a summary #109394.

For this PR, I have checked locally. I can confirm core dump file could be 
debugged with this change.

https://github.com/llvm/llvm-project/pull/112296
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Dhruv Srivastava via lldb-commits

https://github.com/DhruvSrivastavaX updated 
https://github.com/llvm/llvm-project/pull/111814

>From 08c9d5ae66ca857d165dc878ebd1b2e0de364a24 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava 
Date: Thu, 10 Oct 2024 02:24:42 -0500
Subject: [PATCH 1/4] Taking base file structure from ELF as reference

---
 .../ObjectFile/XCOFF/ObjectFileXCOFF.h| 440 ++
 1 file changed, 440 insertions(+)
 create mode 100644 lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h

diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h 
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h
new file mode 100644
index 00..aba3a5bfcbf5b6
--- /dev/null
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h
@@ -0,0 +1,440 @@
+//===-- ObjectFileELF.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_OBJECTFILE_ELF_OBJECTFILEELF_H
+#define LLDB_SOURCE_PLUGINS_OBJECTFILE_ELF_OBJECTFILEELF_H
+
+#include 
+
+#include 
+#include 
+
+#include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/UUID.h"
+#include "lldb/lldb-private.h"
+
+#include "ELFHeader.h"
+
+struct ELFNote {
+  elf::elf_word n_namesz = 0;
+  elf::elf_word n_descsz = 0;
+  elf::elf_word n_type = 0;
+
+  std::string n_name;
+
+  ELFNote() = default;
+
+  /// Parse an ELFNote entry from the given DataExtractor starting at position
+  /// \p offset.
+  ///
+  /// \param[in] data
+  ///The DataExtractor to read from.
+  ///
+  /// \param[in,out] offset
+  ///Pointer to an offset in the data.  On return the offset will be
+  ///advanced by the number of bytes read.
+  ///
+  /// \return
+  ///True if the ELFRel entry was successfully read and false otherwise.
+  bool Parse(const lldb_private::DataExtractor &data, lldb::offset_t *offset);
+
+  size_t GetByteSize() const {
+return 12 + llvm::alignTo(n_namesz, 4) + llvm::alignTo(n_descsz, 4);
+  }
+};
+
+/// \class ObjectFileELF
+/// Generic ELF object file reader.
+///
+/// This class provides a generic ELF (32/64 bit) reader plugin implementing
+/// the ObjectFile protocol.
+class ObjectFileELF : public lldb_private::ObjectFile {
+public:
+  // Static Functions
+  static void Initialize();
+
+  static void Terminate();
+
+  static llvm::StringRef GetPluginNameStatic() { return "elf"; }
+
+  static llvm::StringRef GetPluginDescriptionStatic() {
+return "ELF object file reader.";
+  }
+
+  static lldb_private::ObjectFile *
+  CreateInstance(const lldb::ModuleSP &module_sp, lldb::DataBufferSP data_sp,
+ lldb::offset_t data_offset, const lldb_private::FileSpec 
*file,
+ lldb::offset_t file_offset, lldb::offset_t length);
+
+  static lldb_private::ObjectFile *CreateMemoryInstance(
+  const lldb::ModuleSP &module_sp, lldb::WritableDataBufferSP data_sp,
+  const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
+
+  static size_t GetModuleSpecifications(const lldb_private::FileSpec &file,
+lldb::DataBufferSP &data_sp,
+lldb::offset_t data_offset,
+lldb::offset_t file_offset,
+lldb::offset_t length,
+lldb_private::ModuleSpecList &specs);
+
+  static bool MagicBytesMatch(lldb::DataBufferSP &data_sp, lldb::addr_t offset,
+  lldb::addr_t length);
+
+  // PluginInterface protocol
+  llvm::StringRef GetPluginName() override { return GetPluginNameStatic(); }
+
+  // LLVM RTTI support
+  static char ID;
+  bool isA(const void *ClassID) const override {
+return ClassID == &ID || ObjectFile::isA(ClassID);
+  }
+  static bool classof(const ObjectFile *obj) { return obj->isA(&ID); }
+
+  // ObjectFile Protocol.
+  bool ParseHeader() override;
+
+  bool SetLoadAddress(lldb_private::Target &target, lldb::addr_t value,
+  bool value_is_offset) override;
+
+  lldb::ByteOrder GetByteOrder() const override;
+
+  bool IsExecutable() const override;
+
+  uint32_t GetAddressByteSize() const override;
+
+  lldb_private::AddressClass GetAddressClass(lldb::addr_t file_addr) override;
+
+  void ParseSymtab(lldb_private::Symtab &symtab) override;
+
+  bool IsStripped() override;
+
+  void CreateSections(lldb_private::SectionList &unified_section_list) 
override;
+
+  void Dump(lldb_private::Stream *s) override;
+
+  lldb_private::ArchSpec GetArchitecture() override;
+
+  lldb_private::UUID GetUUID() override;
+
+  /// Return the contents of the .gnu_debuglink section, if the object file
+  

[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only

lawn123 wrote:

There is confusion, I will revise it later.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 2882bb1 - [lldb][docs] Add link to LoongArch tracking issue

2024-10-17 Thread David Spickett via lldb-commits

Author: David Spickett
Date: 2024-10-17T12:48:03+01:00
New Revision: 2882bb192b07674bc11fd5ddd5a4fa6cea194628

URL: 
https://github.com/llvm/llvm-project/commit/2882bb192b07674bc11fd5ddd5a4fa6cea194628
DIFF: 
https://github.com/llvm/llvm-project/commit/2882bb192b07674bc11fd5ddd5a4fa6cea194628.diff

LOG: [lldb][docs] Add link to LoongArch tracking issue

https://github.com/llvm/llvm-project/issues/112693 will be
tracking the overall state of LoongArch support.

This means anyone can check without having to track down
an expert.

Added: 


Modified: 
lldb/docs/index.rst

Removed: 




diff  --git a/lldb/docs/index.rst b/lldb/docs/index.rst
index 2c7d7dbfad9a50..b91077d660894a 100644
--- a/lldb/docs/index.rst
+++ b/lldb/docs/index.rst
@@ -81,9 +81,11 @@ are welcome:
 expected to work, with functionality improving rapidly. ARM and AArch64 support
 is more experimental, with more known issues than the others.
 
-RISC-V support is in active development, refer to the
-`tracking issue `_
-for the current status.
+Support for the following architectures is in active development. For their
+current state, follow the links to their respective issues:
+
+* `RISC-V `_
+* `LoongArch `_
 
 Get Involved
 



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test] Add test for ASTImporter's name conflict resolution (PR #112566)

2024-10-17 Thread Michael Buch via lldb-commits

Michael137 wrote:

> I think this is one of those tests that should really be an API test. As far 
> as I can tell, there's nothing darwin-specific about this bug -- except for 
> the fact that building shared libraries in a cross-platform manner is hard. 
> But the API tests have wrappers that let us do that, and they even support 
> windows. (I had a feeling our docs already stated that shared libraries is a 
> reason to make something an API test, but I can't find that now.)

Yea that makes sense. Adding a `system-darwin` requirement did feel off.

> I understand the desire to not skip a test (and that making it an API test 
> will make that even harder, as a crash will bring down the entire test), but 
> I'm not sure if that's so useful as to override this. I also think that 
> making a test which checks that something fails in a particular way can be 
> fragile (as a random refactor could make it fail in a different way).

True, I've seen this be an issue in the past, especially with ASTImporter 
tests. I was considering adding a warning (or log message at the very least) 
when we try to overwrite and already mapped decl. We could technically XFAIL on 
that. But yea that's probably too fragile. Ideally we'd just test that we 
successfully run the expression.

> From the looks of things, it may be possible to get rid of the dlopen/dlsym 
> thing as well (replace it with hard shared library dependencies) -- it seems 
> the important part is that the two modules have different definitions of one 
> type, and the way that the shared library is loaded is beside the point.

Yup, that should work!

https://github.com/llvm/llvm-project/pull/112566
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 9c80eb7 - Silence -Wswitch after cb43021e5726a4462f28a999fb66a8dc20dc354b

2024-10-17 Thread Benjamin Kramer via lldb-commits

Author: Benjamin Kramer
Date: 2024-10-17T13:15:05+02:00
New Revision: 9c80eb7c83c6471d4126ef46f85bf673787de521

URL: 
https://github.com/llvm/llvm-project/commit/9c80eb7c83c6471d4126ef46f85bf673787de521
DIFF: 
https://github.com/llvm/llvm-project/commit/9c80eb7c83c6471d4126ef46f85bf673787de521.diff

LOG: Silence -Wswitch after cb43021e5726a4462f28a999fb66a8dc20dc354b

lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:4885:13: warning: 
enumeration value 'SveMFloat8' not handled in switch [-Wswitch]
 4885 | switch (llvm::cast(qual_type)->getKind()) {
  |

Added: 


Modified: 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp

Removed: 




diff  --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index fe0c53a7e9a3ea..50115a638b9589 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -5065,6 +5065,7 @@ lldb::Encoding 
TypeSystemClang::GetEncoding(lldb::opaque_compiler_type_t type,
 case clang::BuiltinType::SveUint64x2:
 case clang::BuiltinType::SveUint64x3:
 case clang::BuiltinType::SveUint64x4:
+case clang::BuiltinType::SveMFloat8:
 case clang::BuiltinType::SveFloat16:
 case clang::BuiltinType::SveBFloat16:
 case clang::BuiltinType::SveBFloat16x2:



___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread via lldb-commits

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 f93258e4aca518cba3d48db59ed6143ca19ca99b 
3471f167a8376432571ac17643ed3795a459f017 --extensions cpp,h -- 
lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp 
lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h 
lldb/tools/lldb-server/SystemInitializerLLGS.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp 
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
index d8c6f9fa84..9e27124ed0 100644
--- a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.cpp
@@ -1,4 +1,5 @@
-//===-- ObjectFileXCOFF.cpp 
-===//
+//===-- ObjectFileXCOFF.cpp
+//-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -10,10 +11,9 @@
 
 #include 
 #include 
-#include 
 #include 
+#include 
 
-#include "lldb/Utility/FileSpecList.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/PluginManager.h"
@@ -23,11 +23,12 @@
 #include "lldb/Host/LZMA.h"
 #include "lldb/Symbol/DWARFCallFrameInfo.h"
 #include "lldb/Symbol/SymbolContext.h"
-#include "lldb/Target/SectionLoadList.h"
 #include "lldb/Target/Process.h"
+#include "lldb/Target/SectionLoadList.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Utility/ArchSpec.h"
 #include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/FileSpecList.h"
 #include "lldb/Utility/LLDBLog.h"
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/RangeMap.h"
@@ -39,11 +40,11 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/BinaryFormat/XCOFF.h"
 #include "llvm/Object/Decompressor.h"
+#include "llvm/Object/XCOFFObjectFile.h"
 #include "llvm/Support/CRC.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
-#include "llvm/Object/XCOFFObjectFile.h"
 
 using namespace llvm;
 using namespace lldb;
@@ -67,11 +68,11 @@ void ObjectFileXCOFF::Terminate() {
 bool UGLY_FLAG_FOR_AIX __attribute__((weak)) = false;
 
 ObjectFile *ObjectFileXCOFF::CreateInstance(const lldb::ModuleSP &module_sp,
-  DataBufferSP data_sp,
-  lldb::offset_t data_offset,
-  const lldb_private::FileSpec *file,
-  lldb::offset_t file_offset,
-  lldb::offset_t length) {
+DataBufferSP data_sp,
+lldb::offset_t data_offset,
+const lldb_private::FileSpec *file,
+lldb::offset_t file_offset,
+lldb::offset_t length) {
   if (!data_sp) {
 data_sp = MapFileData(*file, length, file_offset);
 if (!data_sp)
@@ -111,9 +112,12 @@ size_t ObjectFileXCOFF::GetModuleSpecifications(
   const size_t initial_count = specs.GetSize();
 
   if (ObjectFileXCOFF::MagicBytesMatch(data_sp, 0, data_sp->GetByteSize())) {
-ArchSpec arch_spec = ArchSpec(eArchTypeXCOFF, XCOFF::TCPU_PPC64, 
LLDB_INVALID_CPUTYPE);
+ArchSpec arch_spec =
+ArchSpec(eArchTypeXCOFF, XCOFF::TCPU_PPC64, LLDB_INVALID_CPUTYPE);
 ModuleSpec spec(file, arch_spec);
-spec.GetArchitecture().SetArchitecture(eArchTypeXCOFF, XCOFF::TCPU_PPC64, 
LLDB_INVALID_CPUTYPE, llvm::Triple::AIX);
+spec.GetArchitecture().SetArchitecture(eArchTypeXCOFF, XCOFF::TCPU_PPC64,
+   LLDB_INVALID_CPUTYPE,
+   llvm::Triple::AIX);
 specs.Append(spec);
   }
   return specs.GetSize() - initial_count;
@@ -121,10 +125,10 @@ size_t ObjectFileXCOFF::GetModuleSpecifications(
 
 static uint32_t XCOFFHeaderSizeFromMagic(uint32_t magic) {
   switch (magic) {
-  /* TODO: 32bit not supported yet
-  case XCOFF::XCOFF32:
-return sizeof(struct llvm::object::XCOFFFileHeader32);
-  */
+/* TODO: 32bit not supported yet
+case XCOFF::XCOFF32:
+  return sizeof(struct llvm::object::XCOFFFileHeader32);
+*/
 
   case XCOFF::XCOFF64:
 return sizeof(struct llvm::object::XCOFFFileHeader64);
@@ -137,57 +141,43 @@ static uint32_t XCOFFHeaderSizeFromMagic(uint32_t magic) {
 }
 
 bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP &data_sp,
-lldb::addr_t data_offset,
-lldb::addr_t data_length) {
-  lldb_private::DataExtractor data; 
+ 

[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits

https://github.com/lawn123 updated 
https://github.com/llvm/llvm-project/pull/112296

>From ba485de763a08f6ff3c7468c1a1bfbbfb25ac48f Mon Sep 17 00:00:00 2001
From: Liu An 
Date: Tue, 15 Oct 2024 10:31:35 +0800
Subject: [PATCH 1/4] [LoongArch64]: Add support for LoongArch64 in elf-core
 for lldb

---
 .../Plugins/Process/elf-core/CMakeLists.txt   |  1 +
 .../RegisterContextPOSIXCore_loongarch64.cpp  | 87 +++
 .../RegisterContextPOSIXCore_loongarch64.h| 62 +
 .../Process/elf-core/ThreadElfCore.cpp|  6 ++
 4 files changed, 156 insertions(+)
 create mode 100644 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
 create mode 100644 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h

diff --git a/lldb/source/Plugins/Process/elf-core/CMakeLists.txt 
b/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
index 72925c835b5c89..7473fa8d41ccb3 100644
--- a/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
+++ b/lldb/source/Plugins/Process/elf-core/CMakeLists.txt
@@ -10,6 +10,7 @@ add_lldb_library(lldbPluginProcessElfCore PLUGIN
   RegisterContextPOSIXCore_s390x.cpp
   RegisterContextPOSIXCore_x86_64.cpp
   RegisterContextPOSIXCore_riscv64.cpp
+  RegisterContextPOSIXCore_loongarch64.cpp
   RegisterUtilities.cpp
 
   LINK_LIBS
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
new file mode 100644
index 00..af192ecbe01e1b
--- /dev/null
+++ 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.cpp
@@ -0,0 +1,87 @@
+//===-- RegisterContextPOSIXCore_loongarch64.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 "RegisterContextPOSIXCore_loongarch64.h"
+
+#include "lldb/Utility/DataBufferHeap.h"
+
+using namespace lldb_private;
+
+std::unique_ptr
+RegisterContextCorePOSIX_loongarch64::Create(Thread &thread,
+ const ArchSpec &arch,
+ const DataExtractor &gpregset,
+ llvm::ArrayRef notes) {
+  return std::unique_ptr(
+  new RegisterContextCorePOSIX_loongarch64(
+  thread,
+  std::make_unique(arch, Flags()),
+  gpregset, notes));
+}
+
+RegisterContextCorePOSIX_loongarch64::RegisterContextCorePOSIX_loongarch64(
+Thread &thread,
+std::unique_ptr register_info,
+const DataExtractor &gpregset, llvm::ArrayRef notes)
+: RegisterContextPOSIX_loongarch64(thread, std::move(register_info)) {
+
+  m_gpr_buffer = std::make_shared(gpregset.GetDataStart(),
+  gpregset.GetByteSize());
+  m_gpr.SetData(m_gpr_buffer);
+  m_gpr.SetByteOrder(gpregset.GetByteOrder());
+
+  ArchSpec arch = m_register_info_up->GetTargetArchitecture();
+  DataExtractor fpregset = getRegset(notes, arch.GetTriple(), FPR_Desc);
+  m_fpr_buffer = std::make_shared(fpregset.GetDataStart(),
+  fpregset.GetByteSize());
+  m_fpr.SetData(m_fpr_buffer);
+  m_fpr.SetByteOrder(fpregset.GetByteOrder());
+}
+
+RegisterContextCorePOSIX_loongarch64::~RegisterContextCorePOSIX_loongarch64() =
+default;
+
+bool RegisterContextCorePOSIX_loongarch64::ReadGPR() { return true; }
+
+bool RegisterContextCorePOSIX_loongarch64::ReadFPR() { return true; }
+
+bool RegisterContextCorePOSIX_loongarch64::WriteGPR() {
+  assert(false && "Writing registers is not allowed for core dumps");
+  return false;
+}
+
+bool RegisterContextCorePOSIX_loongarch64::WriteFPR() {
+  assert(false && "Writing registers is not allowed for core dumps");
+  return false;
+}
+
+bool RegisterContextCorePOSIX_loongarch64::ReadRegister(
+const RegisterInfo *reg_info, RegisterValue &value) {
+  const uint8_t *src = nullptr;
+  lldb::offset_t offset = reg_info->byte_offset;
+
+  if (IsGPR(reg_info->kinds[lldb::eRegisterKindLLDB])) {
+src = m_gpr.GetDataStart();
+  } else if (IsFPR(reg_info->kinds[lldb::eRegisterKindLLDB])) {
+src = m_fpr.GetDataStart();
+offset -= GetGPRSize();
+  } else {
+return false;
+  }
+
+  Status error;
+  value.SetFromMemoryData(*reg_info, src + offset, reg_info->byte_size,
+  lldb::eByteOrderLittle, error);
+  return error.Success();
+}
+
+bool RegisterContextCorePOSIX_loongarch64::WriteRegister(
+const RegisterInfo *reg_info, const RegisterValue &value) {
+  return false;
+}
diff --git 
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch64.h 
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_loongarch6

[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

lawn123 wrote:

ok


https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

lawn123 wrote:

ok


https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")

lawn123 wrote:

> Is LoongArch one LLVM target or do you need to specifically have LoongArch64 
> for this?

LoongArch is one of the targets of LLVM, and no special processing is required 
here.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")

lawn123 wrote:

> Is LoongArch one LLVM target or do you need to specifically have LoongArch64 
> for this?

LoongArch is one of the targets of LLVM, and no special processing is required 
here.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

lawn123 wrote:

fcc* is 8 bit . fcsr is 4 byte.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")

lawn123 wrote:

> Is LoongArch one LLVM target or do you need to specifically have LoongArch64 
> for this?

LoongArch is one of the targets of LLVM, and no special processing is required 
here.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

lawn123 wrote:

fcc* is 8 bit . fcsr is 4 byte.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

lawn123 wrote:

fcc* is 8 bit . fcsr is 4 byte.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-loongarch64.core")
+
+values = {}
+values["r0"] = "0x"
+values["r1"] = "0x0001216c"
+values["r2"] = "0x"
+values["r3"] = "0x7b8249e0"
+values["r4"] = "0x"
+values["r5"] = "0x0001210c"
+values["r6"] = "0x"
+values["r7"] = "0x"
+values["r8"] = "0x"
+values["r9"] = "0x"
+values["r10"] = "0x"
+values["r11"] = "0x00dd"
+values["r12"] = "0x"
+values["r13"] = "0x002f"
+values["r14"] = "0x"
+values["r15"] = "0x"
+values["r16"] = "0x"
+values["r17"] = "0x"
+values["r18"] = "0x"
+values["r19"] = "0x"
+values["r20"] = "0x"
+values["r21"] = "0x"
+values["r22"] = "0x7b824a10"
+values["r23"] = "0x"
+values["r24"] = "0x"
+values["r25"] = "0x"
+values["r26"] = "0x"
+values["r27"] = "0x"
+values["r28"] = "0x"
+values["r29"] = "0x"
+values["r30"] = "0x"
+values["r31"] = "0x"
+values["orig_a0"] = "0x56b62d50"
+values["pc"] = "0x0001212c"
+
+fpr_values = {}
+fpr_values["f0"] = "0xff05"
+fpr_values["f1"] = "0x2525252525252525"
+fpr_values["f2"] = "0x2525252525560005"
+fpr_values["f3"] = "0x"
+fpr_values["f4"] = "0x"
+fpr_values["f5"] = "0x0008"
+fpr_values["f6"] = "0x0f0e0d0c0b0a0908"
+fpr_values["f7"] = "0x"
+fpr_values["f8"] = "0x6261747563657845"
+fpr_values["f9"] = "0x766173206562206c"
+fpr_values["f10"] = "0x"
+fpr_values["f11"] = "0x"
+fpr_values["f12"] = "0x"
+fpr_values["f13"] = "0x"
+fpr_values["f14"] = "0x"
+fpr_values["f15"] = "0x"
+fpr_values["f16"] = "0x"
+fpr_values["f17"] = "0x"
+fpr_values["f18"] = "0x"
+fpr_values["f19"] = "0x"
+fpr_values["f20"] = "0x"
+fpr_values["f21"] = "0x"
+fpr_values["f22"] = "0x"
+fpr_values["f23"] = "0x"
+fpr_values["f24"] = "0x"
+fpr_values["f25"] = "0x"
+fpr_values["f26"] = "0x"
+fpr_values["f27"] = "0x"
+fpr_values["f28"] = "0x"
+fpr_values["f29"] = "0x"
+fpr_values["f30"] = "0x"
+fpr_values["f31"] = "0x"
+fpr_values["fcc0"] = "0x01"
+fpr_values["fcc1"] = "0x00"
+fpr_values["fcc2"] = "0x01"
+fpr_values["fcc3"] = "0x01"
+fpr_values["fcc4"] = "0x01"
+fpr_values["fcc5"] = "0x01"
+fpr_values["fcc6"] = "0x00"
+fpr_values["fcc7"] = "0x01"
+fpr_values["fcsr"] = "0x00"

lawn123 wrote:

ok


https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits




lawn123 wrote:

> You may be able to reduce the file by changing the 
> `/proc/pid/coredump_filter` value: 
> https://man7.org/linux/man-pages/man5/core.5.html

I reduced the core file size to 36kb.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Don't exit the main loop when in runs out of things to listen on (PR #112565)

2024-10-17 Thread Michał Górny via lldb-commits

https://github.com/mgorny approved this pull request.

I guess LGTM but I haven't given it really deep thought.

https://github.com/llvm/llvm-project/pull/112565
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Lu Weining via lldb-commits

SixWeining wrote:

> For RISC-V I have been using #55383 as the tracking issue for overall 
> support. If you want to, you could open a similar issue and write out what 
> currently works, and I'll link to it from the [main lldb 
> page](https://lldb.llvm.org/#platform-support). Not a requirement, just if 
> you have the time.

Thanks. I just filed #112693. 

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread Liu An via lldb-commits


@@ -833,6 +845,107 @@ def test_riscv64_regs_gpr_only(self):
 substrs=["registers were unavailable"],
 )
 
+@skipIfLLVMTargetMissing("LoongArch")
+def test_loongarch64_regs(self):
+# check registers using 64 bit LoongArch64 core file containing 
GP-registers only

lawn123 wrote:

There is confusion, I will revise it later.

https://github.com/llvm/llvm-project/pull/112296
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Dhruv Srivastava via lldb-commits

https://github.com/DhruvSrivastavaX updated 
https://github.com/llvm/llvm-project/pull/111814

>From 08c9d5ae66ca857d165dc878ebd1b2e0de364a24 Mon Sep 17 00:00:00 2001
From: Dhruv-Srivastava 
Date: Thu, 10 Oct 2024 02:24:42 -0500
Subject: [PATCH 1/5] Taking base file structure from ELF as reference

---
 .../ObjectFile/XCOFF/ObjectFileXCOFF.h| 440 ++
 1 file changed, 440 insertions(+)
 create mode 100644 lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h

diff --git a/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h 
b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h
new file mode 100644
index 00..aba3a5bfcbf5b6
--- /dev/null
+++ b/lldb/source/Plugins/ObjectFile/XCOFF/ObjectFileXCOFF.h
@@ -0,0 +1,440 @@
+//===-- ObjectFileELF.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_OBJECTFILE_ELF_OBJECTFILEELF_H
+#define LLDB_SOURCE_PLUGINS_OBJECTFILE_ELF_OBJECTFILEELF_H
+
+#include 
+
+#include 
+#include 
+
+#include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/UUID.h"
+#include "lldb/lldb-private.h"
+
+#include "ELFHeader.h"
+
+struct ELFNote {
+  elf::elf_word n_namesz = 0;
+  elf::elf_word n_descsz = 0;
+  elf::elf_word n_type = 0;
+
+  std::string n_name;
+
+  ELFNote() = default;
+
+  /// Parse an ELFNote entry from the given DataExtractor starting at position
+  /// \p offset.
+  ///
+  /// \param[in] data
+  ///The DataExtractor to read from.
+  ///
+  /// \param[in,out] offset
+  ///Pointer to an offset in the data.  On return the offset will be
+  ///advanced by the number of bytes read.
+  ///
+  /// \return
+  ///True if the ELFRel entry was successfully read and false otherwise.
+  bool Parse(const lldb_private::DataExtractor &data, lldb::offset_t *offset);
+
+  size_t GetByteSize() const {
+return 12 + llvm::alignTo(n_namesz, 4) + llvm::alignTo(n_descsz, 4);
+  }
+};
+
+/// \class ObjectFileELF
+/// Generic ELF object file reader.
+///
+/// This class provides a generic ELF (32/64 bit) reader plugin implementing
+/// the ObjectFile protocol.
+class ObjectFileELF : public lldb_private::ObjectFile {
+public:
+  // Static Functions
+  static void Initialize();
+
+  static void Terminate();
+
+  static llvm::StringRef GetPluginNameStatic() { return "elf"; }
+
+  static llvm::StringRef GetPluginDescriptionStatic() {
+return "ELF object file reader.";
+  }
+
+  static lldb_private::ObjectFile *
+  CreateInstance(const lldb::ModuleSP &module_sp, lldb::DataBufferSP data_sp,
+ lldb::offset_t data_offset, const lldb_private::FileSpec 
*file,
+ lldb::offset_t file_offset, lldb::offset_t length);
+
+  static lldb_private::ObjectFile *CreateMemoryInstance(
+  const lldb::ModuleSP &module_sp, lldb::WritableDataBufferSP data_sp,
+  const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
+
+  static size_t GetModuleSpecifications(const lldb_private::FileSpec &file,
+lldb::DataBufferSP &data_sp,
+lldb::offset_t data_offset,
+lldb::offset_t file_offset,
+lldb::offset_t length,
+lldb_private::ModuleSpecList &specs);
+
+  static bool MagicBytesMatch(lldb::DataBufferSP &data_sp, lldb::addr_t offset,
+  lldb::addr_t length);
+
+  // PluginInterface protocol
+  llvm::StringRef GetPluginName() override { return GetPluginNameStatic(); }
+
+  // LLVM RTTI support
+  static char ID;
+  bool isA(const void *ClassID) const override {
+return ClassID == &ID || ObjectFile::isA(ClassID);
+  }
+  static bool classof(const ObjectFile *obj) { return obj->isA(&ID); }
+
+  // ObjectFile Protocol.
+  bool ParseHeader() override;
+
+  bool SetLoadAddress(lldb_private::Target &target, lldb::addr_t value,
+  bool value_is_offset) override;
+
+  lldb::ByteOrder GetByteOrder() const override;
+
+  bool IsExecutable() const override;
+
+  uint32_t GetAddressByteSize() const override;
+
+  lldb_private::AddressClass GetAddressClass(lldb::addr_t file_addr) override;
+
+  void ParseSymtab(lldb_private::Symtab &symtab) override;
+
+  bool IsStripped() override;
+
+  void CreateSections(lldb_private::SectionList &unified_section_list) 
override;
+
+  void Dump(lldb_private::Stream *s) override;
+
+  lldb_private::ArchSpec GetArchitecture() override;
+
+  lldb_private::UUID GetUUID() override;
+
+  /// Return the contents of the .gnu_debuglink section, if the object file
+  

[Lldb-commits] [lldb] [lldb][AIX] Added XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Dhruv Srivastava via lldb-commits

DhruvSrivastavaX wrote:

Hi @labath , 
I have dropped some base structure and yaml test cases for the ObjectFileXCOFF 
support. 
Please provide your comments. 

https://github.com/llvm/llvm-project/pull/111814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -3895,3 +3924,103 @@ std::optional 
ObjectFileELF::GetDynamicData() {
   }
   return std::nullopt;
 }
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+  // Every ELF file which represents an executable or shared library has
+  // mandatory .dynamic entries. The DT_SYMTAB value contains a pointer to the
+  // symbol table, and DT_SYMENT contains the size of a symbol table entry.
+  // We then can use either the DT_HASH or DT_GNU_HASH to find the number of
+  // symbols in the symbol table as the symbol count is not stored in the
+  // .dynamic section as a key/value pair.
+  //
+  // When loading and ELF file from memory, only the program headers end up
+  // being mapped into memory, and we can find these values in the PT_DYNAMIC
+  // segment.
+  num_symbols = 0;
+  // Get the process in case this is an in memory ELF file.
+  ProcessSP process_sp(m_process_wp.lock());
+  const ELFDynamic *symtab = FindDynamicSymbol(DT_SYMTAB);
+  const ELFDynamic *syment = FindDynamicSymbol(DT_SYMENT);
+  const ELFDynamic *hash = FindDynamicSymbol(DT_HASH);
+  const ELFDynamic *gnu_hash = FindDynamicSymbol(DT_GNU_HASH);
+  // DT_SYMTAB and DT_SYMENT are mandatory.
+  if (symtab == nullptr || syment == nullptr)
+return std::nullopt;
+  // We must have either a DT_HASH or a DT_GNU_HASH.
+  if (hash == nullptr && gnu_hash == nullptr)
+return std::nullopt;
+  // The number of symbols in the symbol table is the number of entries in the
+  // symbol table divided by the size of each symbol table entry.
+  // We must figure out the number of symbols in the symbol table using the
+  // DT_HASH or the DT_GNU_HASH as the number of symbols isn't stored anywhere
+  // in the .dynamic section.
+
+  lldb::offset_t offset;
+  if (hash) {
+// The DT_HASH header contains the number of symbols in the "nchain"
+// member. The header looks like this:
+// struct DT_HASH_HEADER {
+//   uint32_t nbucket;
+//   uint32_t nchain;
+// };
+if (auto data = ReadDataFromDynamic(hash, 8)) {
+  offset = 4;
+  num_symbols = data->GetU32(&offset);
+}
+  }
+  if (num_symbols == 0 && gnu_hash) {
+struct DT_GNU_HASH_HEADER {

labath wrote:

It doesn't look like there's an existing struct with this name (in any project) 
so I'd prefer something more similar to our existing naming convention -- 
(Dt)GnuHashHeader?

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -3895,3 +3924,103 @@ std::optional 
ObjectFileELF::GetDynamicData() {
   }
   return std::nullopt;
 }
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+  // Every ELF file which represents an executable or shared library has
+  // mandatory .dynamic entries. The DT_SYMTAB value contains a pointer to the
+  // symbol table, and DT_SYMENT contains the size of a symbol table entry.
+  // We then can use either the DT_HASH or DT_GNU_HASH to find the number of
+  // symbols in the symbol table as the symbol count is not stored in the
+  // .dynamic section as a key/value pair.
+  //
+  // When loading and ELF file from memory, only the program headers end up
+  // being mapped into memory, and we can find these values in the PT_DYNAMIC
+  // segment.
+  num_symbols = 0;
+  // Get the process in case this is an in memory ELF file.
+  ProcessSP process_sp(m_process_wp.lock());
+  const ELFDynamic *symtab = FindDynamicSymbol(DT_SYMTAB);
+  const ELFDynamic *syment = FindDynamicSymbol(DT_SYMENT);
+  const ELFDynamic *hash = FindDynamicSymbol(DT_HASH);
+  const ELFDynamic *gnu_hash = FindDynamicSymbol(DT_GNU_HASH);
+  // DT_SYMTAB and DT_SYMENT are mandatory.
+  if (symtab == nullptr || syment == nullptr)
+return std::nullopt;
+  // We must have either a DT_HASH or a DT_GNU_HASH.
+  if (hash == nullptr && gnu_hash == nullptr)
+return std::nullopt;
+  // The number of symbols in the symbol table is the number of entries in the
+  // symbol table divided by the size of each symbol table entry.
+  // We must figure out the number of symbols in the symbol table using the
+  // DT_HASH or the DT_GNU_HASH as the number of symbols isn't stored anywhere
+  // in the .dynamic section.
+
+  lldb::offset_t offset;
+  if (hash) {
+// The DT_HASH header contains the number of symbols in the "nchain"
+// member. The header looks like this:
+// struct DT_HASH_HEADER {
+//   uint32_t nbucket;
+//   uint32_t nchain;
+// };
+if (auto data = ReadDataFromDynamic(hash, 8)) {
+  offset = 4;
+  num_symbols = data->GetU32(&offset);
+}
+  }
+  if (num_symbols == 0 && gnu_hash) {

labath wrote:

This code is rather involved, and it would be better to have it in a helper 
function. Then it could also use early returns for some of the paths. I'd 
recommend something like:
```
if (std::optional syms = GetNumSymbolsFromHash())
  num_symbols = *syms;
else if (std::optional syms = GetNumSymbolsFromDtHash())  
  num_symbols = *syms;
...
```

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -3895,3 +3924,103 @@ std::optional 
ObjectFileELF::GetDynamicData() {
   }
   return std::nullopt;
 }
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+  // Every ELF file which represents an executable or shared library has
+  // mandatory .dynamic entries. The DT_SYMTAB value contains a pointer to the
+  // symbol table, and DT_SYMENT contains the size of a symbol table entry.
+  // We then can use either the DT_HASH or DT_GNU_HASH to find the number of
+  // symbols in the symbol table as the symbol count is not stored in the
+  // .dynamic section as a key/value pair.
+  //
+  // When loading and ELF file from memory, only the program headers end up
+  // being mapped into memory, and we can find these values in the PT_DYNAMIC
+  // segment.
+  num_symbols = 0;
+  // Get the process in case this is an in memory ELF file.
+  ProcessSP process_sp(m_process_wp.lock());
+  const ELFDynamic *symtab = FindDynamicSymbol(DT_SYMTAB);
+  const ELFDynamic *syment = FindDynamicSymbol(DT_SYMENT);
+  const ELFDynamic *hash = FindDynamicSymbol(DT_HASH);
+  const ELFDynamic *gnu_hash = FindDynamicSymbol(DT_GNU_HASH);
+  // DT_SYMTAB and DT_SYMENT are mandatory.
+  if (symtab == nullptr || syment == nullptr)
+return std::nullopt;
+  // We must have either a DT_HASH or a DT_GNU_HASH.
+  if (hash == nullptr && gnu_hash == nullptr)
+return std::nullopt;
+  // The number of symbols in the symbol table is the number of entries in the
+  // symbol table divided by the size of each symbol table entry.
+  // We must figure out the number of symbols in the symbol table using the
+  // DT_HASH or the DT_GNU_HASH as the number of symbols isn't stored anywhere
+  // in the .dynamic section.
+
+  lldb::offset_t offset;

labath wrote:

Declare this where its being initialized (the `offset` used for parsing DT_HASH 
and the one used for DT_GNU_HASH are conceptually unrelated and could be 
separate vars).

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,631 @@
+## This test verifies that loading an ELF file that has no section headers can
+## load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+## the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+## segment.
+##
+## This test will convert a shared library from yaml, strip its section 
headers,
+## and varify that LLDB can load the dynamic symbol table. We must manually
+## strip the section headers from a full shared library because our ELF YAML
+## support in obj2yaml/yaml2obj doesn't support ELF files with program headers
+## only, they must have sections or the file doesn't get recreated correctlty.
+
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-strip --strip-sections %t -o %t.noshdrs
+
+# RUN: %lldb -b \
+# RUN:   -o "target create -d '%t.noshdrs'" \
+# RUN:   -o "image dump objfile" \
+# RUN:   | FileCheck %s --dump-input=always
+# CHECK: (lldb) image dump objfile
+# CHECK: Dumping headers for 1 module(s).
+# CHECK: ObjectFileELF, file =
+# CHECK: ELF Header
+# Make sure there are no section headers
+# CHECK: e_shnum = 0x
+# Make sure we were able to load the symbols
+# CHECK: elf-dynsym.yaml.tmp.noshdrs, num_symbols = 9:
+# CHECK: [ 0] 1 Undefined 0x 0x 0x0022 
__cxa_finalize
+# CHECK: [ 1] 2 X Undefined 0x 0x 0x0012 
puts
+# CHECK: [ 2] 3 Undefined 0x 0x 0x0020 
_ITM_deregisterTMCloneTable
+# CHECK: [ 3] 4 Undefined 0x 0x 0x0020 
__gmon_start__
+# CHECK: [ 4] 5 Undefined 0x 0x 0x0020 
_ITM_registerTMCloneTable
+# CHECK: [ 5] 6 X Code 0x1135 0x0016 0x0012 baz()
+# CHECK: [ 6] 7 X Code 0x111f 0x0016 0x0012 bar()
+# CHECK: [ 7] 8 X Code 0x114b 0x0016 0x0012 biz()
+# CHECK: [ 8] 9 X Code 0x1109 0x0016 0x0012 foo()
+
+--- !ELF

labath wrote:

This input contains a lot of data that's irrelevant for the test. Can you make 
it smaller? For example, something like `llvm-mc -triple=x86_64-pc-linux 
-filetype=obj -o - - <<<".globl defined, undefined; defined:" | ld.lld 
/dev/stdin -o - --hash-style=gnu -export-dynamic` produces a much smaller file 
which still has a dynamic section, and you can control exactly which entries it 
contains (in practice you may want to expand the input slightly, just so that 
all the symbols don't end up with the same value).

You could yamlize that, or even just leave that as the input to the test itself 
(it should be deterministic enough). If you go with the second option, you can 
add `-z nosectionheader` to the linker command to skip the `llvm-strip` step.

I think think that another test with the DT_HASH hash style would be in order 
(just change the above command to --hash-style=sysv)

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -44,6 +44,8 @@
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/MipsABIFlags.h"
+#include "lldb/Target/Process.h"
+

labath wrote:

btw, this grouping of include blocks with empty lines is an lldb-ism (other 
llvm subprojects don't have that), and one not very strictly adhered to (it 
looks like this file does not put lldb includes in a separate block). One 
problem with adding empty lines like that is that it prevents clang-format from 
sorting the includes. Right now clang-format (correctly) wants to put this 
include next to the other lldb includes. If you added an empty line, it would 
leave it alone, thinking that is intentional (which I don't think it is).

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -3895,3 +3924,103 @@ std::optional 
ObjectFileELF::GetDynamicData() {
   }
   return std::nullopt;
 }
+
+
+std::optional
+ObjectFileELF::GetDynsymDataFromDynamic(uint32_t &num_symbols) {
+  // Every ELF file which represents an executable or shared library has
+  // mandatory .dynamic entries. The DT_SYMTAB value contains a pointer to the
+  // symbol table, and DT_SYMENT contains the size of a symbol table entry.
+  // We then can use either the DT_HASH or DT_GNU_HASH to find the number of
+  // symbols in the symbol table as the symbol count is not stored in the
+  // .dynamic section as a key/value pair.
+  //
+  // When loading and ELF file from memory, only the program headers end up
+  // being mapped into memory, and we can find these values in the PT_DYNAMIC
+  // segment.
+  num_symbols = 0;
+  // Get the process in case this is an in memory ELF file.
+  ProcessSP process_sp(m_process_wp.lock());
+  const ELFDynamic *symtab = FindDynamicSymbol(DT_SYMTAB);
+  const ELFDynamic *syment = FindDynamicSymbol(DT_SYMENT);
+  const ELFDynamic *hash = FindDynamicSymbol(DT_HASH);
+  const ELFDynamic *gnu_hash = FindDynamicSymbol(DT_GNU_HASH);
+  // DT_SYMTAB and DT_SYMENT are mandatory.
+  if (symtab == nullptr || syment == nullptr)
+return std::nullopt;
+  // We must have either a DT_HASH or a DT_GNU_HASH.
+  if (hash == nullptr && gnu_hash == nullptr)
+return std::nullopt;
+  // The number of symbols in the symbol table is the number of entries in the
+  // symbol table divided by the size of each symbol table entry.
+  // We must figure out the number of symbols in the symbol table using the
+  // DT_HASH or the DT_GNU_HASH as the number of symbols isn't stored anywhere
+  // in the .dynamic section.
+
+  lldb::offset_t offset;
+  if (hash) {
+// The DT_HASH header contains the number of symbols in the "nchain"
+// member. The header looks like this:
+// struct DT_HASH_HEADER {
+//   uint32_t nbucket;
+//   uint32_t nchain;
+// };
+if (auto data = ReadDataFromDynamic(hash, 8)) {
+  offset = 4;
+  num_symbols = data->GetU32(&offset);
+}
+  }
+  if (num_symbols == 0 && gnu_hash) {
+struct DT_GNU_HASH_HEADER {
+  uint32_t nbuckets = 0;
+  uint32_t symoffset = 0;
+  uint32_t bloom_size = 0;
+  uint32_t bloom_shift = 0;
+};
+if (auto data = ReadDataFromDynamic(gnu_hash, sizeof(DT_GNU_HASH_HEADER))) 
{

labath wrote:

This could use a short description (or a link to one) of the format of the 
section. Nothing too involved, just a couple of sentences to let the reader 
know what to expect..

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-10-17 Thread via lldb-commits

ldrumm wrote:

I've let this patch stew for long enough, and I think it's now time. The 
spurious test failures in files unchanged by this patch have gone away. After 
re-reading the discussion above I'm ready to merge these changes.

There's been a good discussion, which helped me polish this a fair bit, and a 
few contentions which needed clarifying or ironing out. The main contention 
seems to have been that what's stored in git's database is always LF - even for 
for windows users or files that *need* CRLF endings (e.g. `.bat`). As I pointed 
out in a few comments 
(e.g.[1](https://github.com/llvm/llvm-project/pull/86318#issuecomment-2078216855),[2](https://github.com/llvm/llvm-project/pull/86318#issuecomment-2078219678),[3](https://github.com/llvm/llvm-project/pull/86318#issuecomment-2078259364))
 it may be unintuitive to store everything in git's internal database with 
normalized LF, but it's how git *checks them out* that's important, and I 
believe I've ironed out any issues here by tracking down files and testcases 
that depend on a particular line-ending style and adding rules for them.

For those who had such concerns, I believe I've clarified the principal and 
pointed out the practicalities that will make life *easier* for windows *and* 
unix contributors.


To summarize:

**No user should need adjust their local config as a result of this change**

- Adrian is in favour
- Fangrui Song has approved
- Chris Bienemann has approved
- Reid Kleckner had some concerns but they were clarified
- Mehdi Amini approves in principle
- Florian had some concerns I *believe* we addressed.
- Aaron and Saleem had some objections that I *believe* I addressed in [this 
comment](https://github.com/llvm/llvm-project/pull/86318#issuecomment-2078259364)
 since I pointed out that the files will be checked out with the correct line 
endings on *all* systems - regardless of local config.

I'll keep an eye on this, and will be happy to react to any issues that arise 
over the next week or so.

Thanks for all the input.

https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [clang-tools-extra] [flang] [lldb] [llvm] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)

2024-10-17 Thread via lldb-commits

https://github.com/ldrumm closed https://github.com/llvm/llvm-project/pull/86318
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Use Locale to convert between std::wstring and std::string (NFC) (PR #112582)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Use Locale to convert between std::wstring and std::string (NFC) (PR #112582)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath commented:

If you can't reproduce this, I can take a look, but I think the failures are 
likely due to the string length problems.

https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Use Locale to convert between std::wstring and std::string (NFC) (PR #112582)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -76,6 +76,46 @@ using namespace lldb_private::line_editor;
 
 #endif // #if LLDB_EDITLINE_USE_WCHAR
 
+#if LLDB_EDITLINE_USE_WCHAR
+std::string ToBytes(const std::wstring &in) {
+  static std::locale locale("C.UTF-8");
+  static const auto &cvt =
+  std::use_facet>(locale);
+
+  const size_t length = in.length();
+  std::string output(length + 1, 0x0);
+
+  std::mbstate_t mbs{};
+  const wchar_t *in_next;
+  char *out_next;
+
+  if (cvt.out(mbs, in.data(), in.data() + length + 1, in_next, output.data(),
+  output.data() + output.length() + 1,
+  out_next) == std::codecvt_base::ok)
+return output;
+  return {};
+}
+
+std::wstring FromBytes(const std::string &in) {
+  static std::locale locale("C.UTF-8");
+  static const auto &cvt =
+  std::use_facet>(locale);
+
+  const size_t length = in.length();
+  std::wstring output(length + 1, 0x0);

labath wrote:

I believe this direction should be ok (even without the spurious +1).

https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Use Locale to convert between std::wstring and std::string (NFC) (PR #112582)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -76,6 +76,46 @@ using namespace lldb_private::line_editor;
 
 #endif // #if LLDB_EDITLINE_USE_WCHAR
 
+#if LLDB_EDITLINE_USE_WCHAR
+std::string ToBytes(const std::wstring &in) {
+  static std::locale locale("C.UTF-8");
+  static const auto &cvt =
+  std::use_facet>(locale);
+
+  const size_t length = in.length();
+  std::string output(length + 1, 0x0);
+
+  std::mbstate_t mbs{};
+  const wchar_t *in_next;
+  char *out_next;
+
+  if (cvt.out(mbs, in.data(), in.data() + length + 1, in_next, output.data(),

labath wrote:

in.begin/end() ?

https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Use Locale to convert between std::wstring and std::string (NFC) (PR #112582)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -76,6 +76,46 @@ using namespace lldb_private::line_editor;
 
 #endif // #if LLDB_EDITLINE_USE_WCHAR
 
+#if LLDB_EDITLINE_USE_WCHAR
+std::string ToBytes(const std::wstring &in) {
+  static std::locale locale("C.UTF-8");
+  static const auto &cvt =
+  std::use_facet>(locale);
+
+  const size_t length = in.length();
+  std::string output(length + 1, 0x0);

labath wrote:

This isn't right. A single wide character can take up to four bytes in the utf8 
encoding. This works in `CompleteCharacter` as it's only interested in a single 
character (and it does the conversion in the other direction).  We might be 
able get away with overapproximating the size, given that the inputs here 
should be fairly small, but adding a loop with  partial conversions should not 
be that hard either.

https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Use Locale to convert between std::wstring and std::string (NFC) (PR #112582)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/112582
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][LoongArch64] Add support for LoongArch64 in elf-core for lldb (PR #112296)

2024-10-17 Thread David Spickett via lldb-commits

DavidSpickett wrote:

Not sure what's going on with the register formatting. It might be that because 
we do a substring comparison, `foo = 0x00` is found in `foo = 0x`.

So I would recommend loading the core file manually and just copying whatever 
`register read` shows. If the formatting is still off, potentially you need to 
update the register sizes or formatting style, but I don't think you need to do 
that in this PR. It can be a follow up to do just that.

Other than that I don't have any objections here, seems like @SixWeining is the 
architecture expert so they can give the final approval.

https://github.com/llvm/llvm-project/pull/112296
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Disable warning about codecvt_utf8 deprecation (NFC) (PR #112446)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath approved this pull request.


https://github.com/llvm/llvm-project/pull/112446
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce Language::AreEquivalentFunctions (PR #112720)

2024-10-17 Thread Felipe de Azevedo Piovezan via lldb-commits


@@ -363,6 +363,14 @@ class Language : public PluginInterface {
 return false;
   }
 
+  /// Returns a boolean indicating whether two symbol contexts correspond to
+  /// the same function. If the plugin has no opinion, it should return 
nullopt.
+  virtual std::optional
+  AreEquivalentFunctions(const SymbolContext &sc1,

felipepiovezan wrote:

Renamed it

https://github.com/llvm/llvm-project/pull/112720
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce Language::AreEquivalentFunctions (PR #112720)

2024-10-17 Thread Felipe de Azevedo Piovezan via lldb-commits

https://github.com/felipepiovezan updated 
https://github.com/llvm/llvm-project/pull/112720

>From 231afe21bc48b3530dc11bc50a24085043807917 Mon Sep 17 00:00:00 2001
From: Felipe de Azevedo Piovezan 
Date: Thu, 17 Oct 2024 06:00:31 -0700
Subject: [PATCH] [lldb] Introduce Language::AreEqualForFrameComparison

This allows languages to provide an opinion on whether two symbol contexts are
equivalent (i.e. belong to the same function).

It is useful to drive the comparisons done by stepping plans that need to ensure
symbol contexts obtained from different points in time are actually the same.
---
 lldb/include/lldb/Target/Language.h| 9 +
 lldb/source/Target/ThreadPlanStepOverRange.cpp | 5 +
 2 files changed, 14 insertions(+)

diff --git a/lldb/include/lldb/Target/Language.h 
b/lldb/include/lldb/Target/Language.h
index 41d8eeef469eab..c9cddee6baa2da 100644
--- a/lldb/include/lldb/Target/Language.h
+++ b/lldb/include/lldb/Target/Language.h
@@ -363,6 +363,15 @@ class Language : public PluginInterface {
 return false;
   }
 
+  /// Returns a boolean indicating whether two symbol contexts are equal for 
the
+  /// purposes of frame comparison. If the plugin has no opinion, it should
+  /// return nullopt.
+  virtual std::optional
+  AreEqualForFrameComparison(const SymbolContext &sc1,
+ const SymbolContext &sc2) const {
+return {};
+  }
+
   /// Returns true if this Language supports exception breakpoints on throw via
   /// a corresponding LanguageRuntime plugin.
   virtual bool SupportsExceptionBreakpointsOnThrow() const { return false; }
diff --git a/lldb/source/Target/ThreadPlanStepOverRange.cpp 
b/lldb/source/Target/ThreadPlanStepOverRange.cpp
index 934f23b3b21a28..ef5b4b5c434d16 100644
--- a/lldb/source/Target/ThreadPlanStepOverRange.cpp
+++ b/lldb/source/Target/ThreadPlanStepOverRange.cpp
@@ -11,6 +11,7 @@
 #include "lldb/Symbol/CompileUnit.h"
 #include "lldb/Symbol/Function.h"
 #include "lldb/Symbol/LineTable.h"
+#include "lldb/Target/Language.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/RegisterContext.h"
 #include "lldb/Target/Target.h"
@@ -103,6 +104,10 @@ void ThreadPlanStepOverRange::SetupAvoidNoDebug(
 
 bool ThreadPlanStepOverRange::IsEquivalentContext(
 const SymbolContext &context) {
+  if (Language *language = Language::FindPlugin(context.GetLanguage()))
+if (std::optional maybe_equivalent =
+language->AreEqualForFrameComparison(context, m_addr_context))
+  return *maybe_equivalent;
   // Match as much as is specified in the m_addr_context: This is a fairly
   // loose sanity check.  Note, sometimes the target doesn't get filled in so I
   // left out the target check.  And sometimes the module comes in as the .o

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce Language::AreEquivalentFunctions (PR #112720)

2024-10-17 Thread via lldb-commits

jimingham wrote:

> > > > do we have in mind any other languages that will implement this?
> > > 
> > > 
> > > I suspect any language wanting to implement this notion of function 
> > > splitting (e.g. all the users of corosplitter) and virtual frames could 
> > > have a use for this
> > 
> > 
> > We already have `.cold` functions that do this in clang. Might be nice to 
> > support that on the llvm side so this could be testable here.
> 
> There are two things that confuse me about this idea:
> 
> * I thought `.cold` functions came from the hot-cold-split pass, not from 
> Clang?

I was speaking loosely, meaning "in the llvm.org not the swift fork of 
llvm-project (and thus testable there).  We'd have to decide which runtime this 
would go in, maybe we need an "assembly language" or a general fallback runtime 
for this?

> * Don't those create a new frame on the stack, i.e. a new CFA?

I don't remember whether they push a frame or tail call.

https://github.com/llvm/llvm-project/pull/112720
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test][NFC] Document DYLIB_NAME Makefile variable (PR #112735)

2024-10-17 Thread Michael Buch via lldb-commits


@@ -13,6 +13,13 @@
 # the building of the a.out executable program.  For example,
 # DYLIB_ONLY := YES
 #
+# When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME
+# controls the name of the produced dylib. E.g., if set to "foo",
+# the generated dylib will be called "foo.",
+# which on Darwin will be "foo.dylib".

Michael137 wrote:

good catch! it was meant to be `libfoo` for the darwin example :)

https://github.com/llvm/llvm-project/pull/112735
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce Language::AreEquivalentFunctions (PR #112720)

2024-10-17 Thread Felipe de Azevedo Piovezan via lldb-commits


@@ -363,6 +363,14 @@ class Language : public PluginInterface {
 return false;
   }
 
+  /// Returns a boolean indicating whether two symbol contexts correspond to
+  /// the same function. If the plugin has no opinion, it should return 
nullopt.
+  virtual std::optional
+  AreEquivalentFunctions(const SymbolContext &sc1,

felipepiovezan wrote:

Yup, that name looks a lot more expressive.

https://github.com/llvm/llvm-project/pull/112720
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix write only file action to truncate the file (PR #112657)

2024-10-17 Thread via lldb-commits

https://github.com/kusmour updated 
https://github.com/llvm/llvm-project/pull/112657

>From 48831c67f07e1199145dbb5538c02f502d3f02bf Mon Sep 17 00:00:00 2001
From: Wanyi Ye 
Date: Mon, 14 Oct 2024 22:37:50 -0700
Subject: [PATCH] [lldb] Fix write only file action to truncate the file

---
 lldb/source/Host/common/FileAction.cpp|  2 +-
 .../python_api/process/io/TestProcessIO.py| 30 +++
 lldb/unittests/Host/FileActionTest.cpp| 25 
 3 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/lldb/source/Host/common/FileAction.cpp 
b/lldb/source/Host/common/FileAction.cpp
index f980d3224640e0..e1c3e14a165ea9 100644
--- a/lldb/source/Host/common/FileAction.cpp
+++ b/lldb/source/Host/common/FileAction.cpp
@@ -41,7 +41,7 @@ bool FileAction::Open(int fd, const FileSpec &file_spec, bool 
read,
 else if (read)
   m_arg = O_NOCTTY | O_RDONLY;
 else
-  m_arg = O_NOCTTY | O_CREAT | O_WRONLY;
+  m_arg = O_NOCTTY | O_CREAT | O_WRONLY | O_TRUNC;
 m_file_spec = file_spec;
 return true;
   } else {
diff --git a/lldb/test/API/python_api/process/io/TestProcessIO.py 
b/lldb/test/API/python_api/process/io/TestProcessIO.py
index 5bb91d2758312d..3b5c7c48c51f4d 100644
--- a/lldb/test/API/python_api/process/io/TestProcessIO.py
+++ b/lldb/test/API/python_api/process/io/TestProcessIO.py
@@ -95,6 +95,36 @@ def test_stdout_stderr_redirection(self):
 error = self.read_error_file_and_delete()
 self.check_process_output(output, error)
 
+@skipIfWindows  # stdio manipulation unsupported on Windows
+@expectedFlakeyLinux(bugnumber="llvm.org/pr26437")
+@skipIfDarwinEmbedded  # debugserver can't create/write files on the device
+def test_stdout_stderr_redirection_to_existing_files(self):
+"""Exercise SBLaunchInfo::AddOpenFileAction() for STDOUT and STDERR 
without redirecting STDIN to output files already exist."""
+self.setup_test()
+self.build()
+self.create_target()
+self.write_file_with_placeholder(self.output_file)
+self.write_file_with_placeholder(self.error_file)
+self.redirect_stdout()
+self.redirect_stderr()
+self.run_process(True)
+output = self.read_output_file_and_delete()
+error = self.read_error_file_and_delete()
+self.check_process_output(output, error)
+
+def write_file_with_placeholder(self, target_file):
+placeholder = "This content should be overwritten."
+if lldb.remote_platform:
+self.runCmd(
+'platform file write "{target}" -d "{data}"'.format(
+target=target_file, data=placeholder
+)
+)
+else:
+f = open(target_file, "w")
+f.write(placeholder)
+f.close()
+
 # target_file - path on local file system or remote file system if running 
remote
 # local_file - path on local system
 def read_file_and_delete(self, target_file, local_file):
diff --git a/lldb/unittests/Host/FileActionTest.cpp 
b/lldb/unittests/Host/FileActionTest.cpp
index b208169aac20e6..3d2c722552c9c2 100644
--- a/lldb/unittests/Host/FileActionTest.cpp
+++ b/lldb/unittests/Host/FileActionTest.cpp
@@ -6,6 +6,8 @@
 //
 
//===--===//
 
+#include 
+
 #include "lldb/Host/FileAction.h"
 #include "gtest/gtest.h"
 
@@ -17,3 +19,26 @@ TEST(FileActionTest, Open) {
   EXPECT_EQ(Action.GetAction(), FileAction::eFileActionOpen);
   EXPECT_EQ(Action.GetFileSpec(), FileSpec("/tmp"));
 }
+
+TEST(FileActionTest, OpenReadWrite) {
+  FileAction Action;
+  Action.Open(48, FileSpec("/tmp_0"), /*read*/ true, /*write*/ true);
+  EXPECT_TRUE(Action.GetActionArgument() & (O_NOCTTY | O_CREAT | O_RDWR));
+  EXPECT_FALSE(Action.GetActionArgument() & O_RDONLY);
+  EXPECT_FALSE(Action.GetActionArgument() & O_WRONLY);
+}
+
+TEST(FileActionTest, OpenReadOnly) {
+  FileAction Action;
+  Action.Open(49, FileSpec("/tmp_1"), /*read*/ true, /*write*/ false);
+  EXPECT_TRUE(Action.GetActionArgument() & (O_NOCTTY | O_RDONLY));
+  EXPECT_FALSE(Action.GetActionArgument() & O_WRONLY);
+}
+
+TEST(FileActionTest, OpenWriteOnly) {
+  FileAction Action;
+  Action.Open(50, FileSpec("/tmp_2"), /*read*/ false, /*write*/ true);
+  EXPECT_TRUE(Action.GetActionArgument() &
+  (O_NOCTTY | O_CREAT | O_WRONLY | O_TRUNC));
+  EXPECT_FALSE(Action.GetActionArgument() & O_RDONLY);
+}

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix write only file action to truncate the file (PR #112657)

2024-10-17 Thread via lldb-commits

https://github.com/kusmour edited 
https://github.com/llvm/llvm-project/pull/112657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Fix write only file action to truncate the file (PR #112657)

2024-10-17 Thread via lldb-commits

kusmour wrote:

@DavidSpickett If you don't mind me asking, how do we add to release note? 
Thanks in advance!

https://github.com/llvm/llvm-project/pull/112657
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] More aggressively deduplicate global warnings based on contents. (PR #112801)

2024-10-17 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Adrian Prantl (adrian-prantl)


Changes

I've been getting complaints from users being spammed by -gmodules missing file 
warnings going out of control because each object file depends on an entire DAG 
of PCM files that usually are all missing at once. To reduce this problem, this 
patch does two things:

1. Module now maintains a DenseMap that is used to display 
each warning only once, based on its actual text.

2. The PCM warning itself is reworded to include less details, such as the DIE 
offset, which is only useful to LLDB developers, who can get this from the 
dwarf log if they need it. Because the detail is omitted the hashing from (1) 
deduplicates the warnings.

rdar://138144624

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


4 Files Affected:

- (modified) lldb/include/lldb/Core/Module.h (+6-3) 
- (modified) lldb/source/Core/Module.cpp (+19-10) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+13-12) 
- (added) lldb/test/Shell/Diagnostics/TestDedupWarnings.test (+22) 


``diff
diff --git a/lldb/include/lldb/Core/Module.h b/lldb/include/lldb/Core/Module.h
index 5589c1c9a350dc..e2a99cc7bcf50b 100644
--- a/lldb/include/lldb/Core/Module.h
+++ b/lldb/include/lldb/Core/Module.h
@@ -30,6 +30,7 @@
 
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLFunctionalExtras.h"
+#include "llvm/ADT/StableHashing.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Chrono.h"
 
@@ -1057,9 +1058,10 @@ class Module : public 
std::enable_shared_from_this,
   /// time for the symbol tables can be aggregated here.
   StatsDuration m_symtab_index_time;
 
-  std::once_flag m_optimization_warning;
-  std::once_flag m_language_warning;
-
+  /// A set of hashes of all warnings and errors, to avoid reporting them
+  /// multiple times to the same Debugger.
+  llvm::DenseMap>
+  m_shown_diagnostics;
   void SymbolIndicesToSymbolContextList(Symtab *symtab,
 std::vector &symbol_indexes,
 SymbolContextList &sc_list);
@@ -1086,6 +1088,7 @@ class Module : public 
std::enable_shared_from_this,
   void ReportWarning(const llvm::formatv_object_base &payload);
   void ReportError(const llvm::formatv_object_base &payload);
   void ReportErrorIfModifyDetected(const llvm::formatv_object_base &payload);
+  std::once_flag *GetDiagnosticOnceFlag(llvm::StringRef msg);
 };
 
 } // namespace lldb_private
diff --git a/lldb/source/Core/Module.cpp b/lldb/source/Core/Module.cpp
index 88cc957e91fac4..1139f7c0bbbae7 100644
--- a/lldb/source/Core/Module.cpp
+++ b/lldb/source/Core/Module.cpp
@@ -1093,8 +1093,8 @@ void Module::ReportWarningOptimization(
   ss << file_name
  << " was compiled with optimization - stepping may behave "
 "oddly; variables may not be available.";
-  Debugger::ReportWarning(std::string(ss.GetString()), debugger_id,
-  &m_optimization_warning);
+  llvm::StringRef msg = ss.GetString();
+  Debugger::ReportWarning(msg.str(), debugger_id, GetDiagnosticOnceFlag(msg));
 }
 
 void Module::ReportWarningUnsupportedLanguage(
@@ -1104,8 +1104,8 @@ void Module::ReportWarningUnsupportedLanguage(
  << Language::GetNameForLanguageType(language)
  << "\". "
 "Inspection of frame variables will be limited.";
-  Debugger::ReportWarning(std::string(ss.GetString()), debugger_id,
-  &m_language_warning);
+  llvm::StringRef msg = ss.GetString();
+  Debugger::ReportWarning(msg.str(), debugger_id, GetDiagnosticOnceFlag(msg));
 }
 
 void Module::ReportErrorIfModifyDetected(
@@ -1125,20 +1125,29 @@ void Module::ReportErrorIfModifyDetected(
   }
 }
 
+std::once_flag *Module::GetDiagnosticOnceFlag(llvm::StringRef msg) {
+  std::lock_guard guard(m_mutex);
+  auto &once_ptr = m_shown_diagnostics[llvm::stable_hash_name(msg)];
+  if (!once_ptr)
+once_ptr = std::make_unique();
+  return once_ptr.get();
+}
+
 void Module::ReportError(const llvm::formatv_object_base &payload) {
   StreamString strm;
   GetDescription(strm.AsRawOstream(), lldb::eDescriptionLevelBrief);
-  strm.PutChar(' ');
-  strm.PutCString(payload.str());
-  Debugger::ReportError(strm.GetString().str());
+  std::string msg = payload.str();
+  strm << ' ' << msg;
+  Debugger::ReportError(strm.GetString().str(), {}, 
GetDiagnosticOnceFlag(msg));
 }
 
 void Module::ReportWarning(const llvm::formatv_object_base &payload) {
   StreamString strm;
   GetDescription(strm.AsRawOstream(), lldb::eDescriptionLevelFull);
-  strm.PutChar(' ');
-  strm.PutCString(payload.str());
-  Debugger::ReportWarning(std::string(strm.GetString()));
+  std::string msg = payload.str();
+  strm << ' ' << msg;
+  Debugger::ReportWarning(strm.GetString().str(), {},
+  GetDiagnosticOnceFlag(msg));
 }
 
 void Module::LogMessage(Log *log, const llvm::formatv_object_base &payload) {
diff --git a/lldb/source/Plug

[Lldb-commits] [lldb] More aggressively deduplicate global warnings based on contents. (PR #112801)

2024-10-17 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl created 
https://github.com/llvm/llvm-project/pull/112801

I've been getting complaints from users being spammed by -gmodules missing file 
warnings going out of control because each object file depends on an entire DAG 
of PCM files that usually are all missing at once. To reduce this problem, this 
patch does two things:

1. Module now maintains a DenseMap that is used to display each 
warning only once, based on its actual text.

2. The PCM warning itself is reworded to include less details, such as the DIE 
offset, which is only useful to LLDB developers, who can get this from the 
dwarf log if they need it. Because the detail is omitted the hashing from (1) 
deduplicates the warnings.

rdar://138144624

>From be3ea4befa6eb010b4e1b1b544d3034ab9f2afa6 Mon Sep 17 00:00:00 2001
From: Adrian Prantl 
Date: Thu, 17 Oct 2024 16:44:07 -0700
Subject: [PATCH] More aggressively deduplicate global warnings based on
 contents.

I've been getting complaints from users being spammed by -gmodules
missing file warnings going out of control because each object file
depends on an entire DAG of PCM files that usually are all missing at
once. To reduce this problem, this patch does two things:

1. Module now maintains a DenseMap that is used to display
each warning only once, based on its actual text.

2. The PCM warning itself is reworded to include less details, such as
the DIE offset, which is only useful to LLDB developers, who can get
this from the dwarf log if they need it. Because the detail is omitted
the hashing from (1) deduplicates the warnings.

rdar://138144624
---
 lldb/include/lldb/Core/Module.h   |  9 --
 lldb/source/Core/Module.cpp   | 29 ---
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 25 
 .../Shell/Diagnostics/TestDedupWarnings.test  | 22 ++
 4 files changed, 60 insertions(+), 25 deletions(-)
 create mode 100644 lldb/test/Shell/Diagnostics/TestDedupWarnings.test

diff --git a/lldb/include/lldb/Core/Module.h b/lldb/include/lldb/Core/Module.h
index 5589c1c9a350dc..e2a99cc7bcf50b 100644
--- a/lldb/include/lldb/Core/Module.h
+++ b/lldb/include/lldb/Core/Module.h
@@ -30,6 +30,7 @@
 
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLFunctionalExtras.h"
+#include "llvm/ADT/StableHashing.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Chrono.h"
 
@@ -1057,9 +1058,10 @@ class Module : public 
std::enable_shared_from_this,
   /// time for the symbol tables can be aggregated here.
   StatsDuration m_symtab_index_time;
 
-  std::once_flag m_optimization_warning;
-  std::once_flag m_language_warning;
-
+  /// A set of hashes of all warnings and errors, to avoid reporting them
+  /// multiple times to the same Debugger.
+  llvm::DenseMap>
+  m_shown_diagnostics;
   void SymbolIndicesToSymbolContextList(Symtab *symtab,
 std::vector &symbol_indexes,
 SymbolContextList &sc_list);
@@ -1086,6 +1088,7 @@ class Module : public 
std::enable_shared_from_this,
   void ReportWarning(const llvm::formatv_object_base &payload);
   void ReportError(const llvm::formatv_object_base &payload);
   void ReportErrorIfModifyDetected(const llvm::formatv_object_base &payload);
+  std::once_flag *GetDiagnosticOnceFlag(llvm::StringRef msg);
 };
 
 } // namespace lldb_private
diff --git a/lldb/source/Core/Module.cpp b/lldb/source/Core/Module.cpp
index 88cc957e91fac4..1139f7c0bbbae7 100644
--- a/lldb/source/Core/Module.cpp
+++ b/lldb/source/Core/Module.cpp
@@ -1093,8 +1093,8 @@ void Module::ReportWarningOptimization(
   ss << file_name
  << " was compiled with optimization - stepping may behave "
 "oddly; variables may not be available.";
-  Debugger::ReportWarning(std::string(ss.GetString()), debugger_id,
-  &m_optimization_warning);
+  llvm::StringRef msg = ss.GetString();
+  Debugger::ReportWarning(msg.str(), debugger_id, GetDiagnosticOnceFlag(msg));
 }
 
 void Module::ReportWarningUnsupportedLanguage(
@@ -1104,8 +1104,8 @@ void Module::ReportWarningUnsupportedLanguage(
  << Language::GetNameForLanguageType(language)
  << "\". "
 "Inspection of frame variables will be limited.";
-  Debugger::ReportWarning(std::string(ss.GetString()), debugger_id,
-  &m_language_warning);
+  llvm::StringRef msg = ss.GetString();
+  Debugger::ReportWarning(msg.str(), debugger_id, GetDiagnosticOnceFlag(msg));
 }
 
 void Module::ReportErrorIfModifyDetected(
@@ -1125,20 +1125,29 @@ void Module::ReportErrorIfModifyDetected(
   }
 }
 
+std::once_flag *Module::GetDiagnosticOnceFlag(llvm::StringRef msg) {
+  std::lock_guard guard(m_mutex);
+  auto &once_ptr = m_shown_diagnostics[llvm::stable_hash_name(msg)];
+  if (!once_ptr)
+once_ptr = std::make_unique();
+  return once_ptr.get();
+}
+
 void Module::ReportError(const llvm::formatv_object_base &payload) {
   StreamString strm;

[Lldb-commits] [lldb] [lldb] Introduce Language::AreEquivalentFunctions (PR #112720)

2024-10-17 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

> > > do we have in mind any other languages that will implement this?
> > 
> > 
> > I suspect any language wanting to implement this notion of function 
> > splitting (e.g. all the users of corosplitter) and virtual frames could 
> > have a use for this
> 
> We already have `.cold` functions that do this in clang. Might be nice to 
> support that on the llvm side so this could be testable here.

M there are two things that confuse me about this idea:

* I thought `.cold` functions came from the hot-cold-split pass, not from Clang?
* Don't those create a new frame on the stack, i.e. a new CFA?

https://github.com/llvm/llvm-project/pull/112720
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] More aggressively deduplicate global warnings based on contents. (PR #112801)

2024-10-17 Thread Jonas Devlieghere via lldb-commits

https://github.com/JDevlieghere approved this pull request.

LGTM, thanks for fixing this! 

https://github.com/llvm/llvm-project/pull/112801
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][test][NFC] Document DYLIB_NAME Makefile variable (PR #112735)

2024-10-17 Thread Alex Langford via lldb-commits


@@ -13,6 +13,13 @@
 # the building of the a.out executable program.  For example,
 # DYLIB_ONLY := YES
 #
+# When specifying one of the DYLIB_*_SOURCES variables, DYLIB_NAME
+# controls the name of the produced dylib. E.g., if set to "foo",
+# the generated dylib will be called "foo.",
+# which on Darwin will be "foo.dylib".

bulbazord wrote:

This is interesting. LLDB makes an assumption that a module named `foo` will be 
turned onto `libfoo.dylib` on Darwin. See `Platform::GetFullNameForDylib`

https://github.com/llvm/llvm-project/pull/112735
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Greg Clayton via lldb-commits


@@ -0,0 +1,631 @@
+## This test verifies that loading an ELF file that has no section headers can
+## load the dynamic symbol table using the DT_SYMTAB, DT_SYMENT, DT_HASH or
+## the DT_GNU_HASH .dynamic key/value pairs that are loaded via the PT_DYNAMIC
+## segment.
+##
+## This test will convert a shared library from yaml, strip its section 
headers,
+## and varify that LLDB can load the dynamic symbol table. We must manually
+## strip the section headers from a full shared library because our ELF YAML
+## support in obj2yaml/yaml2obj doesn't support ELF files with program headers
+## only, they must have sections or the file doesn't get recreated correctlty.
+
+# RUN: yaml2obj %s -o %t
+# RUN: llvm-strip --strip-sections %t -o %t.noshdrs
+
+# RUN: %lldb -b \
+# RUN:   -o "target create -d '%t.noshdrs'" \
+# RUN:   -o "image dump objfile" \
+# RUN:   | FileCheck %s --dump-input=always
+# CHECK: (lldb) image dump objfile
+# CHECK: Dumping headers for 1 module(s).
+# CHECK: ObjectFileELF, file =
+# CHECK: ELF Header
+# Make sure there are no section headers
+# CHECK: e_shnum = 0x
+# Make sure we were able to load the symbols
+# CHECK: elf-dynsym.yaml.tmp.noshdrs, num_symbols = 9:
+# CHECK: [ 0] 1 Undefined 0x 0x 0x0022 
__cxa_finalize
+# CHECK: [ 1] 2 X Undefined 0x 0x 0x0012 
puts
+# CHECK: [ 2] 3 Undefined 0x 0x 0x0020 
_ITM_deregisterTMCloneTable
+# CHECK: [ 3] 4 Undefined 0x 0x 0x0020 
__gmon_start__
+# CHECK: [ 4] 5 Undefined 0x 0x 0x0020 
_ITM_registerTMCloneTable
+# CHECK: [ 5] 6 X Code 0x1135 0x0016 0x0012 baz()
+# CHECK: [ 6] 7 X Code 0x111f 0x0016 0x0012 bar()
+# CHECK: [ 7] 8 X Code 0x114b 0x0016 0x0012 biz()
+# CHECK: [ 8] 9 X Code 0x1109 0x0016 0x0012 foo()
+
+--- !ELF

clayborg wrote:

I am happy to use the llvm-mc + ld.lld trick, bit I need:
- the output file to have a .dynamic section or PT_DYNAMIC (above example 
doesn't)
- it needs to have a dynamic symbol table (SHT_DYNSYM or .dynamic section needs 
to have `DT_SYMTAB` and `DT_SYMENT` entries
- Needs to have a DT_HASH or DT_GNU_HASH

I don't know much about the `llvm-mc` tool, but if you can get it to generate a 
file that i can use I will use it.

https://github.com/llvm/llvm-project/pull/112596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Add support for reading the dynamic symbol table from PT_DYNAMIC (PR #112596)

2024-10-17 Thread Greg Clayton via lldb-commits

https://github.com/clayborg updated 
https://github.com/llvm/llvm-project/pull/112596

>From 890d2bcf655a2e1e58b025cc0df7b4e42956e4c6 Mon Sep 17 00:00:00 2001
From: Greg Clayton 
Date: Sat, 28 Sep 2024 15:05:37 -0700
Subject: [PATCH 1/2] Add support for reading the dynamic symbol table from
 program headers and PT_DYNAMIC.

Allow LLDB to parse the dynamic symbol table from an ELF file or memory image 
in an ELF file that has no section headers. This patch uses the ability to 
parse the PT_DYNAMIC segment and find the DT_SYMTAB, DT_SYMENT, DT_HASH or 
DT_GNU_HASH to find and parse the dynamic symbol table if the section headers 
are not present. It also adds a helper function to read data from a .dynamic 
key/value pair entry correctly from the file or from memory.
---
 .../Plugins/ObjectFile/ELF/ObjectFileELF.cpp  | 163 -
 .../Plugins/ObjectFile/ELF/ObjectFileELF.h|  34 +
 .../test/Shell/ObjectFile/ELF/elf-dynsym.yaml | 631 ++
 3 files changed, 811 insertions(+), 17 deletions(-)
 create mode 100644 lldb/test/Shell/ObjectFile/ELF/elf-dynsym.yaml

diff --git a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp 
b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
index 10d09662c0a47a..7374ac10a1e27a 100644
--- a/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ b/lldb/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -44,6 +44,8 @@
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/MipsABIFlags.h"
+#include "lldb/Target/Process.h"
+
 
 #define CASE_AND_STREAM(s, def, width) 
\
   case def:
\
@@ -2990,18 +2992,34 @@ void ObjectFileELF::ParseSymtab(Symtab &lldb_symtab) {
   // section, nomatter if .symtab was already parsed or not. This is because
   // minidebuginfo normally removes the .symtab symbols which have their
   // matching .dynsym counterparts.
+  bool found_dynsym = false;
   if (!symtab ||
   GetSectionList()->FindSectionByName(ConstString(".gnu_debugdata"))) {
 Section *dynsym =
 section_list->FindSectionByType(eSectionTypeELFDynamicSymbols, true)
 .get();
 if (dynsym) {
+  found_dynsym = true;
   auto [num_symbols, address_class_map] =
   ParseSymbolTable(&lldb_symtab, symbol_id, dynsym);
   symbol_id += num_symbols;
   m_address_class_map.merge(address_class_map);
 }
   }
+  if (!found_dynsym) {
+// Try and read the dynamic symbol table from the .dynamic section.
+uint32_t num_symbols = 0;
+std::optional symtab_data =
+GetDynsymDataFromDynamic(num_symbols);
+std::optional strtab_data = GetDynstrData();
+if (symtab_data && strtab_data) {
+  auto [num_symbols_parsed, address_class_map] =
+  ParseSymbols(&lldb_symtab, symbol_id, section_list, num_symbols,
+symtab_data.value(), strtab_data.value());
+  symbol_id += num_symbols_parsed;
+  m_address_class_map.merge(address_class_map);
+}
+  }
 
   // DT_JMPREL
   //  If present, this entry's d_ptr member holds the address of
@@ -3811,6 +3829,33 @@ ObjectFileELF::MapFileDataWritable(const FileSpec &file, 
uint64_t Size,
  Offset);
 }
 
+std::optional
+ObjectFileELF::ReadDataFromDynamic(const ELFDynamic *dyn, uint64_t length,
+   uint64_t offset) {
+  // ELFDynamic values contain a "d_ptr" member that will be a load address if
+  // we have an ELF file read from memory, or it will be a file address if it
+  // was read from a ELF file. This function will correctly fetch data pointed
+  // to by the ELFDynamic::d_ptr, or return std::nullopt if the data isn't
+  // available.
+  const lldb::addr_t d_ptr_addr = dyn->d_ptr + offset;
+  if (ProcessSP process_sp = m_process_wp.lock()) {
+if (DataBufferSP data_sp = ReadMemory(process_sp, d_ptr_addr, length))
+  return DataExtractor(data_sp, GetByteOrder(), GetAddressByteSize());
+  } else {
+// We have an ELF file with no section headers or we didn't find the
+// .dynamic section. Try and find the .dynstr section.
+Address addr;
+if (!addr.ResolveAddressUsingFileSections(d_ptr_addr, GetSectionList()))
+  return std::nullopt;
+DataExtractor data;
+addr.GetSection()->GetSectionData(data);
+return DataExtractor(data,
+ d_ptr_addr - addr.GetSection()->GetFileAddress(),
+ length);
+  }
+  return std::nullopt;
+}
+
 std::optional ObjectFileELF::GetDynstrData() {
   if (SectionList *section_list = GetSectionList()) {
 // Find the SHT_DYNAMIC section.
@@ -3846,23 +3891,7 @@ std::optional 
ObjectFileELF::GetDynstrData() {
   if (strtab == nullptr || strsz == nullptr)
 return std::nullopt;
 
-  if (ProcessSP process_sp = m_process_wp.lock()) {
-if (DataBufferSP data_sp =
-ReadMemory(process_s

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (PR #108448)

2024-10-17 Thread Greg Clayton via lldb-commits

https://github.com/clayborg approved this pull request.


https://github.com/llvm/llvm-project/pull/108448
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 5033ea7 - [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (#108448)

2024-10-17 Thread via lldb-commits

Author: Jacob Lalonde
Date: 2024-10-17T15:26:05-07:00
New Revision: 5033ea73bb01061feb09b3216c74619e1fbefdeb

URL: 
https://github.com/llvm/llvm-project/commit/5033ea73bb01061feb09b3216c74619e1fbefdeb
DIFF: 
https://github.com/llvm/llvm-project/commit/5033ea73bb01061feb09b3216c74619e1fbefdeb.diff

LOG: [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (#108448)

Recently my coworker @jeffreytan81 pointed out that Minidumps don't show
breakpoints when collected. This was prior blocked because Minidumps
could only contain 1 exception, now that we support N signals/sections
we can save all the threads stopped on breakpoints.

Added: 

lldb/test/API/functionalities/postmortem/minidump-new/linux-x86_64-exceptiondescription.yaml

Modified: 
lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.h
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp
lldb/test/API/functionalities/postmortem/minidump-new/TestMiniDumpNew.py
llvm/include/llvm/BinaryFormat/Minidump.h

Removed: 




diff  --git a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp 
b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
index f6c16b6e3d96ae..bcac5edbc1a793 100644
--- a/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
+++ b/lldb/source/Plugins/ObjectFile/Minidump/MinidumpFileBuilder.cpp
@@ -75,8 +75,7 @@ Status 
MinidumpFileBuilder::AddHeaderAndCalculateDirectories() {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
 if (stop_info_sp) {
   const StopReason &stop_reason = stop_info_sp->GetStopReason();
-  if (stop_reason == StopReason::eStopReasonException ||
-  stop_reason == StopReason::eStopReasonSignal)
+  if (stop_reason != lldb::eStopReasonInvalid)
 m_expected_directories++;
 }
   }
@@ -685,50 +684,45 @@ Status MinidumpFileBuilder::AddExceptions() {
   Status error;
   for (const ThreadSP &thread_sp : thread_list) {
 StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
-bool add_exception = false;
-if (stop_info_sp) {
-  switch (stop_info_sp->GetStopReason()) {
-  case eStopReasonSignal:
-  case eStopReasonException:
-add_exception = true;
-break;
-  default:
-break;
-  }
-}
-if (add_exception) {
-  constexpr size_t minidump_exception_size =
-  sizeof(llvm::minidump::ExceptionStream);
-  error = AddDirectory(StreamType::Exception, minidump_exception_size);
-  if (error.Fail())
-return error;
+// If we don't have a stop info, or if it's invalid, skip.
+if (!stop_info_sp ||
+stop_info_sp->GetStopReason() == lldb::eStopReasonInvalid)
+  continue;
 
-  StopInfoSP stop_info_sp = thread_sp->GetStopInfo();
-  RegisterContextSP reg_ctx_sp(thread_sp->GetRegisterContext());
-  Exception exp_record = {};
-  exp_record.ExceptionCode =
-  static_cast(stop_info_sp->GetValue());
-  exp_record.ExceptionFlags = static_cast(0);
-  exp_record.ExceptionRecord = static_cast(0);
-  exp_record.ExceptionAddress = reg_ctx_sp->GetPC();
-  exp_record.NumberParameters = static_cast(0);
-  exp_record.UnusedAlignment = static_cast(0);
-  // exp_record.ExceptionInformation;
-
-  ExceptionStream exp_stream;
-  exp_stream.ThreadId =
-  static_cast(thread_sp->GetID());
-  exp_stream.UnusedAlignment = static_cast(0);
-  exp_stream.ExceptionRecord = exp_record;
-  auto Iter = m_tid_to_reg_ctx.find(thread_sp->GetID());
-  if (Iter != m_tid_to_reg_ctx.end()) {
-exp_stream.ThreadContext = Iter->second;
-  } else {
-exp_stream.ThreadContext.DataSize = 0;
-exp_stream.ThreadContext.RVA = 0;
-  }
-  m_data.AppendData(&exp_stream, minidump_exception_size);
+constexpr size_t minidump_exception_size =
+sizeof(llvm::minidump::ExceptionStream);
+error = AddDirectory(StreamType::Exception, minidump_exception_size);
+if (error.Fail())
+  return error;
+
+RegisterContextSP reg_ctx_sp(thread_sp->GetRegisterContext());
+Exception exp_record = {};
+exp_record.ExceptionCode =
+static_cast(stop_info_sp->GetValue());
+exp_record.ExceptionFlags =
+static_cast(Exception::LLDB_FLAG);
+exp_record.ExceptionRecord = static_cast(0);
+exp_record.ExceptionAddress = reg_ctx_sp->GetPC();
+exp_record.NumberParameters = static_cast(1);
+std::string description = stop_info_sp->GetDescription();
+// We have 120 bytes to work with and it's unlikely description will
+// overflow, but we gotta check.
+memcpy(&exp_record.ExceptionInformation, description.c_str(),
+   std::max(description.size(), Exception::MaxParameterBytes));
+exp_record.UnusedAlignment = static_cast(0);
+ExceptionStream exp_stream;
+exp_strea

[Lldb-commits] [lldb] [llvm] [LLDB][Minidump] Add breakpoint stop reasons to the minidump. (PR #108448)

2024-10-17 Thread Jacob Lalonde via lldb-commits

https://github.com/Jlalond closed 
https://github.com/llvm/llvm-project/pull/108448
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Improve unwinding for discontinuous functions (PR #111409)

2024-10-17 Thread Jason Molenda via lldb-commits

jasonmolenda wrote:

FTR I have an intel mac running the same OS as the CI bots (`LLVM host triple: 
x86_64-apple-darwin22.6.0` it's macOS 13.5 aka macOS Ventura from 2022), and am 
building github main so I can try to repo this failure and Alex's on this shell 
test.  I don't really think I'm going to repo it, I haven't with any other 
macOS version.  I won't be able to look at it until next week but it's as close 
to the CI bots as I can get, hopefully this repos the fail.

https://github.com/llvm/llvm-project/pull/111409
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][ClangASTImporter][NFC] Emit a log message when we break MapImported invariant (PR #112748)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -1158,11 +1175,7 @@ void 
ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
   to_tag->setCompleteDefinition(from_tag->isCompleteDefinition());
 
   if (Log *log_ast = GetLog(LLDBLog::AST)) {
-std::string name_string;
-if (NamedDecl *from_named_decl = dyn_cast(from)) {
-  llvm::raw_string_ostream name_stream(name_string);
-  from_named_decl->printName(name_stream);
-}
+std::string name_string = getDeclName(from);

labath wrote:

You might as well put this call directly into the log message (line 1184)

https://github.com/llvm/llvm-project/pull/112748
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][ClangASTImporter][NFC] Emit a log message when we break MapImported invariant (PR #112748)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -1136,6 +1136,25 @@ ClangASTImporter::ASTImporterDelegate::ImportImpl(Decl 
*From) {
 
 void ClangASTImporter::ASTImporterDelegate::ImportDefinitionTo(
 clang::Decl *to, clang::Decl *from) {
+  Log *log = GetLog(LLDBLog::Expressions);
+
+  auto getDeclName = [](Decl const *decl) {
+std::string name_string;
+if (auto const *from_named_decl = dyn_cast(decl)) {
+  llvm::raw_string_ostream name_stream(name_string);
+  from_named_decl->printName(name_stream);
+}
+
+return name_string;
+  };
+
+  if (auto *D = GetAlreadyImportedOrNull(from); D && D != to)

labath wrote:

If this is expensive (I honestly don't know), you may want to put this in a 
`if(log)` block.

https://github.com/llvm/llvm-project/pull/112748
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][ClangASTImporter][NFC] Emit a log message when we break MapImported invariant (PR #112748)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath approved this pull request.


https://github.com/llvm/llvm-project/pull/112748
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Avoid repeated map lookups (NFC) (PR #112823)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -102,11 +102,9 @@ llvm::Error CommandObjectMultiword::LoadUserSubcommand(
 
   std::string str_name(name);
 
-  auto pos = m_subcommand_dict.find(str_name);
-  if (pos == m_subcommand_dict.end()) {
-m_subcommand_dict[str_name] = cmd_obj_sp;
+  auto [pos, inserted] = m_subcommand_dict.try_emplace(str_name, cmd_obj_sp);
+  if (inserted)
 return llvm::Error::success();
-  }
 
   const char *error_str = nullptr;
   if (!can_replace)

labath wrote:

I guess line 118 could also be `pos->second = cmd_obj_sp;`

https://github.com/llvm/llvm-project/pull/112823
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Avoid repeated map lookups (NFC) (PR #112823)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath approved this pull request.


https://github.com/llvm/llvm-project/pull/112823
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #112811)

2024-10-17 Thread Zequan Wu via lldb-commits

https://github.com/ZequanWu created 
https://github.com/llvm/llvm-project/pull/112811

This is the second half of https://github.com/llvm/llvm-project/pull/90008.

Essentially, it replace the work of resolving template types when we just need 
the qualified names with walking the DIE tree in `DWARFTypePrinter`. 

>From e996ae0076881bc9f660f75baeb9522ff7af49e4 Mon Sep 17 00:00:00 2001
From: Zequan Wu 
Date: Wed, 9 Oct 2024 22:35:46 -0700
Subject: [PATCH] [lldb][dwarf] Compute fully qualified names on simplified
 template names with DWARFTypePrinter

---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  | 19 ++
 .../Plugins/SymbolFile/DWARF/DWARFBaseDIE.h   | 11 ++
 .../Plugins/SymbolFile/DWARF/DWARFDIE.cpp | 35 ++
 .../Plugins/SymbolFile/DWARF/DWARFDIE.h   | 15 
 .../SymbolFile/DWARF/DWARFFormValue.cpp   | 25 +
 .../Plugins/SymbolFile/DWARF/DWARFFormValue.h |  5 +++
 .../SymbolFile/DWARF/SymbolFileDWARF.cpp  | 36 +--
 .../TypeSystem/Clang/TypeSystemClang.cpp  | 20 ---
 .../TypeSystem/Clang/TypeSystemClang.h|  4 ---
 .../DWARF/x86/simplified-template-names.cpp   | 31 
 llvm/include/llvm/DebugInfo/DWARF/DWARFDie.h  |  2 ++
 .../llvm/DebugInfo/DWARF/DWARFTypePrinter.h   | 31 ++--
 llvm/lib/DebugInfo/DWARF/DWARFDie.cpp |  9 +
 13 files changed, 175 insertions(+), 68 deletions(-)
 create mode 100644 
lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp

diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index a30d898a93cc4d..d0d61a8489f3cc 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -44,6 +44,7 @@
 #include "clang/AST/DeclTemplate.h"
 #include "clang/AST/Type.h"
 #include "llvm/ADT/StringExtras.h"
+#include "llvm/DebugInfo/DWARF/DWARFTypePrinter.h"
 #include "llvm/Demangle/Demangle.h"
 
 #include 
@@ -825,11 +826,11 @@ std::string 
DWARFASTParserClang::GetDIEClassTemplateParams(DWARFDIE die) {
   if (llvm::StringRef(die.GetName()).contains("<"))
 return {};
 
-  TypeSystemClang::TemplateParameterInfos template_param_infos;
-  if (ParseTemplateParameterInfos(die, template_param_infos))
-return m_ast.PrintTemplateParams(template_param_infos);
-
-  return {};
+  std::string result;
+  llvm::raw_string_ostream os(result);
+  llvm::DWARFTypePrinter p(os);
+  p.appendAndTerminateTemplateParameters(die);
+  return result;
 }
 
 void DWARFASTParserClang::MapDeclDIEToDefDIE(
@@ -1617,9 +1618,9 @@ void DWARFASTParserClang::GetUniqueTypeNameAndDeclaration(
 case DW_TAG_structure_type:
 case DW_TAG_union_type: {
   if (const char *class_union_struct_name = parent_decl_ctx_die.GetName()) 
{
+qualified_name.insert(0, "::");
 qualified_name.insert(
 0, GetDIEClassTemplateParams(parent_decl_ctx_die));
-qualified_name.insert(0, "::");
 qualified_name.insert(0, class_union_struct_name);
   }
   parent_decl_ctx_die = parent_decl_ctx_die.GetParentDeclContextDIE();
@@ -1672,6 +1673,12 @@ DWARFASTParserClang::ParseStructureLikeDIE(const 
SymbolContext &sc,
   if (attrs.name) {
 GetUniqueTypeNameAndDeclaration(die, cu_language, unique_typename,
 unique_decl);
+if (log) {
+  dwarf->GetObjectFile()->GetModule()->LogMessage(
+  log, "SymbolFileDWARF({0:p}) - {1:x16}: {2} has unique name: {3} ",
+  static_cast(this), die.GetID(), DW_TAG_value_to_name(tag),
+  unique_typename.AsCString());
+}
 if (UniqueDWARFASTType *unique_ast_entry_type =
 dwarf->GetUniqueDWARFASTTypeMap().Find(
 unique_typename, die, unique_decl, byte_size,
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
index 235343d2271223..d9d40a84f3300f 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
@@ -24,9 +24,11 @@ class DWARFUnit;
 class DWARFDebugInfoEntry;
 class DWARFDeclContext;
 class SymbolFileDWARF;
+class DWARFFormValue;
 
 class DWARFBaseDIE {
 public:
+  using DWARFFormValue = dwarf::DWARFFormValue;
   DWARFBaseDIE() = default;
 
   DWARFBaseDIE(DWARFUnit *cu, DWARFDebugInfoEntry *die)
@@ -46,6 +48,7 @@ class DWARFBaseDIE {
   explicit operator bool() const { return IsValid(); }
 
   bool IsValid() const { return m_cu && m_die; }
+  bool isValid() const { return IsValid(); }
 
   bool HasChildren() const;
 
@@ -85,6 +88,10 @@ class DWARFBaseDIE {
   // Accessing information about a DIE
   dw_tag_t Tag() const;
 
+  dw_tag_t getTag() const {
+return Tag();
+  }
+
   dw_offset_t GetOffset() const;
 
   // Get the LLDB user ID for this DIE. This is often just the DIE offset,
@@ -95,6 +102,10 @@ class DWARFBaseDIE 

[Lldb-commits] [lldb] 9c6f85f - [lldb][NFC] fix two small typeos in aarch64-linxu.md

2024-10-17 Thread Jason Molenda via lldb-commits

Author: Jason Molenda
Date: 2024-10-17T19:46:08-07:00
New Revision: 9c6f85f57a74278e4833f3da2606d80e7577d6d5

URL: 
https://github.com/llvm/llvm-project/commit/9c6f85f57a74278e4833f3da2606d80e7577d6d5
DIFF: 
https://github.com/llvm/llvm-project/commit/9c6f85f57a74278e4833f3da2606d80e7577d6d5.diff

LOG: [lldb][NFC] fix two small typeos in aarch64-linxu.md

Added: 


Modified: 
lldb/docs/use/aarch64-linux.md

Removed: 




diff  --git a/lldb/docs/use/aarch64-linux.md b/lldb/docs/use/aarch64-linux.md
index 803f56d16f981e..70432f57857a59 100644
--- a/lldb/docs/use/aarch64-linux.md
+++ b/lldb/docs/use/aarch64-linux.md
@@ -160,7 +160,7 @@ Kernel does.
 ### Visibility of an Inactive ZA Register
 
 LLDB does not handle registers that can come and go at runtime (SVE changes
-size but it does not dissappear). Therefore when `za` is not enabled, LLDB
+size but it does not disappear). Therefore when `za` is not enabled, LLDB
 will return a block of 0s instead. This block will match the expected size of
 `za`:
 ```
@@ -183,9 +183,9 @@ If you want to know whether `za` is active or not, refer to 
bit 2 of the
 
 As for SVE, LLDB does not know how the debugee will use `za`, and therefore
 does not know how it would be best to display it. At any time any given
-instrucion could interpret its contents as many kinds and sizes of data.
+instruction could interpret its contents as many kinds and sizes of data.
 
-So LLDB will default to showing  `za` as one large vector of individual bytes.
+So LLDB will default to showing `za` as one large vector of individual bytes.
 You can override this with a format option (see the SVE example above).
 
 ### Expression Evaluation
@@ -228,4 +228,4 @@ bytes.
 ### Expression Evaluation
 
 `zt0`'s value and whether it is active or not will be saved prior to
-expression evaluation and restored afterwards.
\ No newline at end of file
+expression evaluation and restored afterwards.



___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.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 "ObjectFileXCOFF.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
+#include "lldb/Symbol/DWARFCallFrameInfo.h"
+#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/SectionLoadList.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/FileSpecList.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RangeMap.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/Stream.h"
+#include "lldb/Utility/Timer.h"
+#include "llvm/ADT/IntervalMap.h"
+#include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/XCOFF.h"
+#include "llvm/Object/Decompressor.h"
+#include "llvm/Object/XCOFFObjectFile.h"
+#include "llvm/Support/CRC.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/MathExtras.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+using namespace llvm;
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ObjectFileXCOFF)
+
+// FIXME: target 64bit at this moment.
+
+// Static methods.
+void ObjectFileXCOFF::Initialize() {
+  PluginManager::RegisterPlugin(GetPluginNameStatic(),
+GetPluginDescriptionStatic(), CreateInstance,
+CreateMemoryInstance, GetModuleSpecifications);
+}
+
+void ObjectFileXCOFF::Terminate() {
+  PluginManager::UnregisterPlugin(CreateInstance);
+}
+
+bool UGLY_FLAG_FOR_AIX __attribute__((weak)) = false;

labath wrote:

I see its used in the dwarf parser. We can deal with that later. My suggestion 
would be to look at how the llvm dwarf parser (llvm-dwarfdump) does this.

https://github.com/llvm/llvm-project/pull/111814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [llvm] [lldb][dwarf] Compute fully qualified names on simplified template names with DWARFTypePrinter (PR #112811)

2024-10-17 Thread via lldb-commits

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 e9eec14bb3566f6578950797559de98678f16985 
e996ae0076881bc9f660f75baeb9522ff7af49e4 --extensions cpp,h -- 
lldb/test/Shell/SymbolFile/DWARF/x86/simplified-template-names.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFDIE.h 
lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp 
lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp 
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h 
llvm/include/llvm/DebugInfo/DWARF/DWARFDie.h 
llvm/include/llvm/DebugInfo/DWARF/DWARFTypePrinter.h 
llvm/lib/DebugInfo/DWARF/DWARFDie.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
index d0d61a8489..fbcbbc666f 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -1619,8 +1619,8 @@ void DWARFASTParserClang::GetUniqueTypeNameAndDeclaration(
 case DW_TAG_union_type: {
   if (const char *class_union_struct_name = parent_decl_ctx_die.GetName()) 
{
 qualified_name.insert(0, "::");
-qualified_name.insert(
-0, GetDIEClassTemplateParams(parent_decl_ctx_die));
+qualified_name.insert(0,
+  GetDIEClassTemplateParams(parent_decl_ctx_die));
 qualified_name.insert(0, class_union_struct_name);
   }
   parent_decl_ctx_die = parent_decl_ctx_die.GetParentDeclContextDIE();
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
index d9d40a84f3..ca25801137 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
@@ -88,9 +88,7 @@ public:
   // Accessing information about a DIE
   dw_tag_t Tag() const;
 
-  dw_tag_t getTag() const {
-return Tag();
-  }
+  dw_tag_t getTag() const { return Tag(); }
 
   dw_offset_t GetOffset() const;
 
@@ -102,9 +100,7 @@ public:
 
   const char *GetName() const;
 
-  const char *getShortName() const {
-return GetName();
-  }
+  const char *getShortName() const { return GetName(); }
 
   lldb::ModuleSP GetModule() const;
 
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
index a3960aadb8..bc5d0a9555 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -576,23 +576,23 @@ std::optional 
DWARFFormValue::getAsUnsignedConstant() const {
 }
 
 std::optional DWARFFormValue::getAsSignedConstant() const {
-if ((!IsDataForm(m_form)) ||
-(m_form == lldb_private::dwarf::DW_FORM_udata &&
- uint64_t(std::numeric_limits::max()) < m_value.uval))
-  return std::nullopt;
-switch (m_form) {
-case lldb_private::dwarf::DW_FORM_data4:
-  return int32_t(m_value.uval);
-case lldb_private::dwarf::DW_FORM_data2:
-  return int16_t(m_value.uval);
-case lldb_private::dwarf::DW_FORM_data1:
-  return int8_t(m_value.uval);
-case lldb_private::dwarf::DW_FORM_sdata:
-case lldb_private::dwarf::DW_FORM_data8:
-default:
-  return m_value.sval;
-}
+  if ((!IsDataForm(m_form)) ||
+  (m_form == lldb_private::dwarf::DW_FORM_udata &&
+   uint64_t(std::numeric_limits::max()) < m_value.uval))
+return std::nullopt;
+  switch (m_form) {
+  case lldb_private::dwarf::DW_FORM_data4:
+return int32_t(m_value.uval);
+  case lldb_private::dwarf::DW_FORM_data2:
+return int16_t(m_value.uval);
+  case lldb_private::dwarf::DW_FORM_data1:
+return int8_t(m_value.uval);
+  case lldb_private::dwarf::DW_FORM_sdata:
+  case lldb_private::dwarf::DW_FORM_data8:
+  default:
+return m_value.sval;
   }
+}
 
 const uint8_t *DWARFFormValue::BlockData() const { return m_value.data; }
 
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h 
b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h
index dd8d653c0f..66fb6e855f 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFFormValue.h
@@ -65,9 +65,7 @@ public:
   int64_t Signed() const { return m_value.sval; }
   void SetSigned(int64_t sval) { m_value.sval = sval; }
   const char *AsCString() const;
-  const char* getAsCString() const {
-return AsCString();
-  }
+  const char *getAsCString() const { return AsCString(); }
   dw_addr_t Addr

[Lldb-commits] [lldb] [lldb] Avoid repeated map lookups (NFC) (PR #112823)

2024-10-17 Thread Kazu Hirata via lldb-commits

https://github.com/kazutakahirata created 
https://github.com/llvm/llvm-project/pull/112823

None

>From 621d5b5a767daa4046dffec522c39e4bc652ac1b Mon Sep 17 00:00:00 2001
From: Kazu Hirata 
Date: Thu, 17 Oct 2024 07:52:35 -0700
Subject: [PATCH] [lldb] Avoid repeated map lookups (NFC)

---
 lldb/source/Commands/CommandObjectMultiword.cpp | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectMultiword.cpp 
b/lldb/source/Commands/CommandObjectMultiword.cpp
index 484d9022027ec6..71339bd0f28b41 100644
--- a/lldb/source/Commands/CommandObjectMultiword.cpp
+++ b/lldb/source/Commands/CommandObjectMultiword.cpp
@@ -102,11 +102,9 @@ llvm::Error CommandObjectMultiword::LoadUserSubcommand(
 
   std::string str_name(name);
 
-  auto pos = m_subcommand_dict.find(str_name);
-  if (pos == m_subcommand_dict.end()) {
-m_subcommand_dict[str_name] = cmd_obj_sp;
+  auto [pos, inserted] = m_subcommand_dict.try_emplace(str_name, cmd_obj_sp);
+  if (inserted)
 return llvm::Error::success();
-  }
 
   const char *error_str = nullptr;
   if (!can_replace)

___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Avoid repeated map lookups (NFC) (PR #112823)

2024-10-17 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Kazu Hirata (kazutakahirata)


Changes



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


1 Files Affected:

- (modified) lldb/source/Commands/CommandObjectMultiword.cpp (+2-4) 


``diff
diff --git a/lldb/source/Commands/CommandObjectMultiword.cpp 
b/lldb/source/Commands/CommandObjectMultiword.cpp
index 484d9022027ec6..71339bd0f28b41 100644
--- a/lldb/source/Commands/CommandObjectMultiword.cpp
+++ b/lldb/source/Commands/CommandObjectMultiword.cpp
@@ -102,11 +102,9 @@ llvm::Error CommandObjectMultiword::LoadUserSubcommand(
 
   std::string str_name(name);
 
-  auto pos = m_subcommand_dict.find(str_name);
-  if (pos == m_subcommand_dict.end()) {
-m_subcommand_dict[str_name] = cmd_obj_sp;
+  auto [pos, inserted] = m_subcommand_dict.try_emplace(str_name, cmd_obj_sp);
+  if (inserted)
 return llvm::Error::success();
-  }
 
   const char *error_str = nullptr;
   if (!can_replace)

``




https://github.com/llvm/llvm-project/pull/112823
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Dhruv Srivastava via lldb-commits

https://github.com/DhruvSrivastavaX edited 
https://github.com/llvm/llvm-project/pull/111814
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.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 "ObjectFileXCOFF.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/Module.h"

labath wrote:

Are all of these needed for the thing that the file is doing? (Please don't 
reduce them too aggressively -- that leads to fragile headers -- but I don't 
think you're using e.g. LZMA or PointerUnion at the moment)

https://github.com/llvm/llvm-project/pull/111814
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.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 "ObjectFileXCOFF.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
+#include "lldb/Symbol/DWARFCallFrameInfo.h"
+#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/SectionLoadList.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/FileSpecList.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RangeMap.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/Stream.h"
+#include "lldb/Utility/Timer.h"
+#include "llvm/ADT/IntervalMap.h"
+#include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/XCOFF.h"
+#include "llvm/Object/Decompressor.h"
+#include "llvm/Object/XCOFFObjectFile.h"
+#include "llvm/Support/CRC.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/MathExtras.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+using namespace llvm;
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ObjectFileXCOFF)
+
+// FIXME: target 64bit at this moment.
+
+// Static methods.
+void ObjectFileXCOFF::Initialize() {
+  PluginManager::RegisterPlugin(GetPluginNameStatic(),
+GetPluginDescriptionStatic(), CreateInstance,
+CreateMemoryInstance, GetModuleSpecifications);
+}
+
+void ObjectFileXCOFF::Terminate() {
+  PluginManager::UnregisterPlugin(CreateInstance);
+}
+
+bool UGLY_FLAG_FOR_AIX __attribute__((weak)) = false;
+
+ObjectFile *ObjectFileXCOFF::CreateInstance(const lldb::ModuleSP &module_sp,
+DataBufferSP data_sp,
+lldb::offset_t data_offset,
+const lldb_private::FileSpec *file,
+lldb::offset_t file_offset,
+lldb::offset_t length) {
+  if (!data_sp) {
+data_sp = MapFileData(*file, length, file_offset);
+if (!data_sp)
+  return nullptr;
+data_offset = 0;
+  }
+
+  if (!ObjectFileXCOFF::MagicBytesMatch(data_sp, data_offset, length))
+return nullptr;
+
+  // Update the data to contain the entire file if it doesn't already
+  if (data_sp->GetByteSize() < length) {
+data_sp = MapFileData(*file, length, file_offset);
+if (!data_sp)
+  return nullptr;
+data_offset = 0;
+  }
+  auto objfile_up = std::make_unique(
+  module_sp, data_sp, data_offset, file, file_offset, length);
+  if (!objfile_up)
+return nullptr;
+
+  UGLY_FLAG_FOR_AIX = true;
+  return objfile_up.release();
+}
+
+ObjectFile *ObjectFileXCOFF::CreateMemoryInstance(
+const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
+const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
+  return nullptr;
+}
+
+size_t ObjectFileXCOFF::GetModuleSpecifications(
+const lldb_private::FileSpec &file, lldb::DataBufferSP &data_sp,
+lldb::offset_t data_offset, lldb::offset_t file_offset,
+lldb::offset_t length, lldb_private::ModuleSpecList &specs) {
+  const size_t initial_count = specs.GetSize();
+
+  if (ObjectFileXCOFF::MagicBytesMatch(data_sp, 0, data_sp->GetByteSize())) {
+ArchSpec arch_spec =
+ArchSpec(eArchTypeXCOFF, XCOFF::TCPU_PPC64, LLDB_INVALID_CPUTYPE);
+ModuleSpec spec(file, arch_spec);
+spec.GetArchitecture().SetArchitecture(eArchTypeXCOFF, XCOFF::TCPU_PPC64,
+   LLDB_INVALID_CPUTYPE,
+   llvm::Triple::AIX);
+specs.Append(spec);
+  }
+  return specs.GetSize() - initial_count;
+}
+
+static uint32_t XCOFFHeaderSizeFromMagic(uint32_t magic) {
+  switch (magic) {
+/* TODO: 32bit not supported yet
+case XCOFF::XCOFF32:
+  return sizeof(struct llvm::object::XCOFFFileHeader32);
+*/
+
+  case XCOFF::XCOFF64:
+return sizeof(struct llvm::object::XCOFFFileHeader64);
+break;
+
+  default:
+break;
+  }
+  return 0;
+}
+
+bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP &data_sp,
+  lldb::addr_t data_offset,
+  lldb::addr_t data_length) {
+  lldb_private::DataExtractor data;
+  data.SetData(data_sp, data_offset, da

[Lldb-commits] [lldb] [lldb][AIX] Added XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath commented:

This is exactly what I had in mind -- thank you.

The patch looks mostly good, apart from the inline comments. My main question 
is about the "dependant modules" parsing code. AFAICT, its not actually 
functional (and not tested). Is yaml2objs xcoff backend sufficiently developed 
to create a test for the dependant module functionality? Given that we rely on 
llvm for parsing that, we don't have to test it extensively, but it would be 
nice to have at least one test. We could either do that in this patch, or rip 
out the dependant module functionality, and add it back in another patch -- up 
to you.

https://github.com/llvm/llvm-project/pull/111814
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits

https://github.com/labath edited 
https://github.com/llvm/llvm-project/pull/111814
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.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 "ObjectFileXCOFF.h"
+
+#include 
+#include 
+#include 

labath wrote:

```suggestion
#include 
```

https://github.com/llvm/llvm-project/pull/111814
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.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 "ObjectFileXCOFF.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
+#include "lldb/Symbol/DWARFCallFrameInfo.h"
+#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/SectionLoadList.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/FileSpecList.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RangeMap.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/Stream.h"
+#include "lldb/Utility/Timer.h"
+#include "llvm/ADT/IntervalMap.h"
+#include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/XCOFF.h"
+#include "llvm/Object/Decompressor.h"
+#include "llvm/Object/XCOFFObjectFile.h"
+#include "llvm/Support/CRC.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/MathExtras.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+using namespace llvm;
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ObjectFileXCOFF)
+
+// FIXME: target 64bit at this moment.
+
+// Static methods.
+void ObjectFileXCOFF::Initialize() {
+  PluginManager::RegisterPlugin(GetPluginNameStatic(),
+GetPluginDescriptionStatic(), CreateInstance,
+CreateMemoryInstance, GetModuleSpecifications);
+}
+
+void ObjectFileXCOFF::Terminate() {
+  PluginManager::UnregisterPlugin(CreateInstance);
+}
+
+bool UGLY_FLAG_FOR_AIX __attribute__((weak)) = false;
+
+ObjectFile *ObjectFileXCOFF::CreateInstance(const lldb::ModuleSP &module_sp,
+DataBufferSP data_sp,
+lldb::offset_t data_offset,
+const lldb_private::FileSpec *file,
+lldb::offset_t file_offset,
+lldb::offset_t length) {
+  if (!data_sp) {
+data_sp = MapFileData(*file, length, file_offset);
+if (!data_sp)
+  return nullptr;
+data_offset = 0;
+  }
+
+  if (!ObjectFileXCOFF::MagicBytesMatch(data_sp, data_offset, length))
+return nullptr;
+
+  // Update the data to contain the entire file if it doesn't already
+  if (data_sp->GetByteSize() < length) {
+data_sp = MapFileData(*file, length, file_offset);
+if (!data_sp)
+  return nullptr;
+data_offset = 0;
+  }
+  auto objfile_up = std::make_unique(
+  module_sp, data_sp, data_offset, file, file_offset, length);
+  if (!objfile_up)
+return nullptr;
+
+  UGLY_FLAG_FOR_AIX = true;
+  return objfile_up.release();
+}
+
+ObjectFile *ObjectFileXCOFF::CreateMemoryInstance(
+const lldb::ModuleSP &module_sp, WritableDataBufferSP data_sp,
+const lldb::ProcessSP &process_sp, lldb::addr_t header_addr) {
+  return nullptr;
+}
+
+size_t ObjectFileXCOFF::GetModuleSpecifications(
+const lldb_private::FileSpec &file, lldb::DataBufferSP &data_sp,
+lldb::offset_t data_offset, lldb::offset_t file_offset,
+lldb::offset_t length, lldb_private::ModuleSpecList &specs) {
+  const size_t initial_count = specs.GetSize();
+
+  if (ObjectFileXCOFF::MagicBytesMatch(data_sp, 0, data_sp->GetByteSize())) {
+ArchSpec arch_spec =
+ArchSpec(eArchTypeXCOFF, XCOFF::TCPU_PPC64, LLDB_INVALID_CPUTYPE);
+ModuleSpec spec(file, arch_spec);
+spec.GetArchitecture().SetArchitecture(eArchTypeXCOFF, XCOFF::TCPU_PPC64,
+   LLDB_INVALID_CPUTYPE,
+   llvm::Triple::AIX);
+specs.Append(spec);
+  }
+  return specs.GetSize() - initial_count;
+}
+
+static uint32_t XCOFFHeaderSizeFromMagic(uint32_t magic) {
+  switch (magic) {
+/* TODO: 32bit not supported yet
+case XCOFF::XCOFF32:
+  return sizeof(struct llvm::object::XCOFFFileHeader32);
+*/
+
+  case XCOFF::XCOFF64:
+return sizeof(struct llvm::object::XCOFFFileHeader64);
+break;
+
+  default:
+break;
+  }
+  return 0;
+}
+
+bool ObjectFileXCOFF::MagicBytesMatch(DataBufferSP &data_sp,
+  lldb::addr_t data_offset,
+  lldb::addr_t data_length) {
+  lldb_private::DataExtractor data;
+  data.SetData(data_sp, data_offset, da

[Lldb-commits] [lldb] [lldb][AIX] Added XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,243 @@
+//===-- ObjectFileXCOFF.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 "ObjectFileXCOFF.h"
+
+#include 
+#include 
+#include 
+#include 
+
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Core/PluginManager.h"
+#include "lldb/Core/Progress.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Host/FileSystem.h"
+#include "lldb/Host/LZMA.h"
+#include "lldb/Symbol/DWARFCallFrameInfo.h"
+#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Process.h"
+#include "lldb/Target/SectionLoadList.h"
+#include "lldb/Target/Target.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/DataBufferHeap.h"
+#include "lldb/Utility/FileSpecList.h"
+#include "lldb/Utility/LLDBLog.h"
+#include "lldb/Utility/Log.h"
+#include "lldb/Utility/RangeMap.h"
+#include "lldb/Utility/Status.h"
+#include "lldb/Utility/Stream.h"
+#include "lldb/Utility/Timer.h"
+#include "llvm/ADT/IntervalMap.h"
+#include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/BinaryFormat/XCOFF.h"
+#include "llvm/Object/Decompressor.h"
+#include "llvm/Object/XCOFFObjectFile.h"
+#include "llvm/Support/CRC.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/MathExtras.h"
+#include "llvm/Support/MemoryBuffer.h"
+
+using namespace llvm;
+using namespace lldb;
+using namespace lldb_private;
+
+LLDB_PLUGIN_DEFINE(ObjectFileXCOFF)
+
+// FIXME: target 64bit at this moment.
+
+// Static methods.
+void ObjectFileXCOFF::Initialize() {
+  PluginManager::RegisterPlugin(GetPluginNameStatic(),
+GetPluginDescriptionStatic(), CreateInstance,
+CreateMemoryInstance, GetModuleSpecifications);
+}
+
+void ObjectFileXCOFF::Terminate() {
+  PluginManager::UnregisterPlugin(CreateInstance);
+}
+
+bool UGLY_FLAG_FOR_AIX __attribute__((weak)) = false;

labath wrote:

We're going to have to find a different way to achieve whatever this is trying 
to achieve. Let's remove that, as it should not be necessary for this patch.

https://github.com/llvm/llvm-project/pull/111814
___
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 XCOFF Object File Header for AIX (PR #111814)

2024-10-17 Thread Pavel Labath via lldb-commits


@@ -0,0 +1,116 @@
+//===-- ObjectFileXCOFF.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_OBJECTFILE_XCOFF_OBJECTFILEXCOFF_H
+#define LLDB_SOURCE_PLUGINS_OBJECTFILE_XCOFF_OBJECTFILEXCOFF_H
+
+#include 
+
+#include 
+
+#include "lldb/Symbol/ObjectFile.h"
+#include "lldb/Utility/ArchSpec.h"
+#include "lldb/Utility/FileSpec.h"
+#include "lldb/Utility/UUID.h"
+#include "lldb/lldb-private.h"
+#include "llvm/Object/XCOFFObjectFile.h"
+
+/// \class ObjectFileXCOFF
+/// Generic XCOFF object file reader.
+///
+/// This class provides a generic XCOFF (32/64 bit) reader plugin implementing
+/// the ObjectFile protocol.
+class ObjectFileXCOFF : public lldb_private::ObjectFile {
+public:
+  // Static Functions
+  static void Initialize();
+
+  static void Terminate();
+
+  static llvm::StringRef GetPluginNameStatic() { return "xcoff"; }
+
+  static llvm::StringRef GetPluginDescriptionStatic() {
+return "XCOFF object file reader.";
+  }
+
+  static lldb_private::ObjectFile *
+  CreateInstance(const lldb::ModuleSP &module_sp, lldb::DataBufferSP data_sp,
+ lldb::offset_t data_offset, const lldb_private::FileSpec 
*file,
+ lldb::offset_t file_offset, lldb::offset_t length);
+
+  static lldb_private::ObjectFile *CreateMemoryInstance(
+  const lldb::ModuleSP &module_sp, lldb::WritableDataBufferSP data_sp,
+  const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
+
+  static size_t GetModuleSpecifications(const lldb_private::FileSpec &file,
+lldb::DataBufferSP &data_sp,
+lldb::offset_t data_offset,
+lldb::offset_t file_offset,
+lldb::offset_t length,
+lldb_private::ModuleSpecList &specs);
+
+  static bool MagicBytesMatch(lldb::DataBufferSP &data_sp, lldb::addr_t offset,
+  lldb::addr_t length);
+
+  static lldb::SymbolType MapSymbolType(llvm::object::SymbolRef::Type 
sym_type);
+
+  // PluginInterface protocol
+  llvm::StringRef GetPluginName() override { return GetPluginNameStatic(); }
+
+  // ObjectFile Protocol.
+  bool ParseHeader() override;
+
+  lldb::ByteOrder GetByteOrder() const override;
+
+  bool IsExecutable() const override;
+
+  uint32_t GetAddressByteSize() const override;
+
+  void ParseSymtab(lldb_private::Symtab &symtab) override;
+
+  bool IsStripped() override;
+
+  void CreateSections(lldb_private::SectionList &unified_section_list) 
override;
+
+  void Dump(lldb_private::Stream *s) override;
+
+  lldb_private::ArchSpec GetArchitecture() override;
+
+  lldb_private::UUID GetUUID() override;
+
+  uint32_t GetDependentModules(lldb_private::FileSpecList &files) override;
+
+  ObjectFile::Type CalculateType() override;
+
+  ObjectFile::Strata CalculateStrata() override;
+
+  ObjectFileXCOFF(const lldb::ModuleSP &module_sp, lldb::DataBufferSP data_sp,
+  lldb::offset_t data_offset,
+  const lldb_private::FileSpec *file, lldb::offset_t offset,
+  lldb::offset_t length);
+
+  ObjectFileXCOFF(const lldb::ModuleSP &module_sp,
+  lldb::DataBufferSP header_data_sp,
+  const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
+
+protected:
+  static lldb::WritableDataBufferSP
+  MapFileDataWritable(const lldb_private::FileSpec &file, uint64_t Size,
+  uint64_t Offset);
+
+  uint32_t ParseDependentModules();
+
+private:
+  std::unique_ptr m_binary;
+  lldb_private::Address m_entry_point_address;
+  std::optional m_deps_filespec;
+  std::map> m_deps_base_members;

labath wrote:

unused, please remove for now.

https://github.com/llvm/llvm-project/pull/111814
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Avoid repeated map lookups (NFC) (PR #112655)

2024-10-17 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

Thanks for finding those, there are many places in LLDB doing repeated work 
like this!

https://github.com/llvm/llvm-project/pull/112655
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Introduce Language::AreEquivalentFunctions (PR #112720)

2024-10-17 Thread Felipe de Azevedo Piovezan via lldb-commits

felipepiovezan wrote:

An example usage can be found here: 
https://github.com/swiftlang/llvm-project/pull/9441

https://github.com/llvm/llvm-project/pull/112720
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


  1   2   >