[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

[Pavel Labath via lldb-commits]

https://github.com/labath created 
https://github.com/llvm/llvm-project/pull/92503

…unction (#91321)"

This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was reverted due 
to a test failure on aarch64/windows. The failure was caused by a combination 
of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang targeting 
other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `` unwind rules is 
recursive
- the test binary creates a very long chain of fp-less function frames (it 
manages to fit about 22k frames before it blows its stack)

Together, these things have caused lldb to recreate the same deep recursion 
when unwinding through this, and blow its own stack as well. Since lldb frames 
are larger, about 4k frames like this was sufficient to trigger the stack 
overflow.

This version of the patch works around this problem by increasing the frame 
size of the test binary, thereby causing it to blow its stack sooner. This 
doesn't fix the issue -- the same problem can occur with a real binary -- but 
it's not very likely, as it requires an infinite recursion in a simple (so it 
doesn't use the frame pointer) function with a very small frame (so you can fit 
a lot of them on the stack).

A more principled fix would be to make lldb's lookup code non-recursive, but I 
believe that's out of scope for this patch.

The original patch description follows:

A leaf function may not store the link register to stack, but we it can still 
end up being a non-zero frame if it gets interrupted by a signal. Currently, we 
were unable to unwind past this function because we could not read the link 
register value.

To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = ` rules. 
This in turn necessitated an adjustment in the generic instruction emulation 
logic to ensure that `lr=[sp-X]` can override the `` rule.
- allows the `` rule for pc and lr in all `m_all_registers_available` 
frames (and not just frame zero).

The test verifies that we can unwind in a situation like this, and that the 
backtrace matches the one we computed before getting a signal.

>From 47858edddfbccf989213d61f3761fcdb04814839 Mon Sep 17 00:00:00 2001
From: Pavel Labath 
Date: Fri, 17 May 2024 06:34:08 +
Subject: [PATCH] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts
 a leaf function (#91321)"

This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was
reverted due to a test failure on aarch64/windows. The failure was
caused by a combination of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang
  targeting other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `` unwind rules
  is recursive
- the test binary creates a very long chain of fp-less function frames
  (it manages to fit about 22k frames before it blows its stack)

Together, these things have caused lldb to recreate the same deep
recursion when unwinding through this, and blow its own stack as well.
Since lldb frames are larger, about 4k frames like this was sufficient
to trigger the stack overflow.

This version of the patch works around this problem by increasing the
frame size of the test binary, thereby causing it to blow its stack
sooner. This doesn't fix the issue -- the same problem can occur with a
real binary -- but it's not very likely, as it requires an infinite
recursion in a simple (so it doesn't use the frame pointer) function
with a very small frame (so you can fit a lot of them on the stack).

A more principled fix would be to make lldb's lookup code non-recursive,
but I believe that's out of scope for this patch.

The original patch description follows:

A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.

To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = `
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`` rule.
- allows the `` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).

The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.
---
 .../ARM64/EmulateInstructionARM64.cpp |  2 ++
 .../UnwindAssemblyInstEmulation.cpp   |  4 +--
 lldb/source/Target/RegisterContextUnwind.cpp  |  6 ++---
 .../API/functionalities/bt-interrupt/main.c   |  1 +
 .../Inputs/signal-in-leaf-function-aarch64.c  | 15 +++
 .../signal-in-leaf-function-aarch64.test  | 27 +++
 .../ARM64/TestArm64InstEmulation.cpp  | 24 ++---
 7 files changed, 69 insertions

[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)


Changes

…unction (#91321)"

This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was reverted due 
to a test failure on aarch64/windows. The failure was caused by a combination 
of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang targeting 
other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `` unwind rules is 
recursive
- the test binary creates a very long chain of fp-less function frames (it 
manages to fit about 22k frames before it blows its stack)

Together, these things have caused lldb to recreate the same deep recursion 
when unwinding through this, and blow its own stack as well. Since lldb frames 
are larger, about 4k frames like this was sufficient to trigger the stack 
overflow.

This version of the patch works around this problem by increasing the frame 
size of the test binary, thereby causing it to blow its stack sooner. This 
doesn't fix the issue -- the same problem can occur with a real binary -- but 
it's not very likely, as it requires an infinite recursion in a simple (so it 
doesn't use the frame pointer) function with a very small frame (so you can fit 
a lot of them on the stack).

A more principled fix would be to make lldb's lookup code non-recursive, but I 
believe that's out of scope for this patch.

The original patch description follows:

A leaf function may not store the link register to stack, but we it can still 
end up being a non-zero frame if it gets interrupted by a signal. Currently, we 
were unable to unwind past this function because we could not read the link 
register value.

To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = ` 
rules. This in turn necessitated an adjustment in the generic instruction 
emulation logic to ensure that `lr=[sp-X]` can override the `` rule.
- allows the `` rule for pc and lr in all 
`m_all_registers_available` frames (and not just frame zero).

The test verifies that we can unwind in a situation like this, and that the 
backtrace matches the one we computed before getting a signal.

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


7 Files Affected:

- (modified) lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp 
(+2) 
- (modified) 
lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
 (+1-3) 
- (modified) lldb/source/Target/RegisterContextUnwind.cpp (+3-3) 
- (modified) lldb/test/API/functionalities/bt-interrupt/main.c (+1) 
- (added) lldb/test/Shell/Unwind/Inputs/signal-in-leaf-function-aarch64.c (+15) 
- (added) lldb/test/Shell/Unwind/signal-in-leaf-function-aarch64.test (+27) 
- (modified) lldb/unittests/UnwindAssembly/ARM64/TestArm64InstEmulation.cpp 
(+20-4) 


``diff
diff --git a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp 
b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
index 6ca4fb052457e..62ecac3e0831d 100644
--- a/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
+++ b/lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
@@ -444,6 +444,8 @@ bool EmulateInstructionARM64::CreateFunctionEntryUnwind(
 
   // Our previous Call Frame Address is the stack pointer
   row->GetCFAValue().SetIsRegisterPlusOffset(gpr_sp_arm64, 0);
+  row->SetRegisterLocationToSame(gpr_lr_arm64, /*must_replace=*/false);
+  row->SetRegisterLocationToSame(gpr_fp_arm64, /*must_replace=*/false);
 
   unwind_plan.AppendRow(row);
   unwind_plan.SetSourceName("EmulateInstructionARM64");
diff --git 
a/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
 
b/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
index c4a171ec7d01b..49edd40544e32 100644
--- 
a/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
+++ 
b/lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
@@ -424,8 +424,6 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
 log->PutString(strm.GetString());
   }
 
-  const bool cant_replace = false;
-
   switch (context.type) {
   default:
   case EmulateInstruction::eContextInvalid:
@@ -467,7 +465,7 @@ size_t UnwindAssemblyInstEmulation::WriteMemory(
 m_pushed_regs[reg_num] = addr;
 const int32_t offset = addr - m_initial_sp;
 m_curr_row->SetRegisterLocationToAtCFAPlusOffset(reg_num, offset,
- cant_replace);
+ /*can_replace=*/true);
 m_curr_row_modified = true;
   }
 }
diff --git a/lldb/source/Target/RegisterContextUnwind.cpp 
b/lldb/source/Target/RegisterContextUnwind.cpp
index 13e101413a477..e2d712cb72eae 100644
--- a/lldb/source/Target/RegisterContextUnwind.cpp
+++ b/lldb/source/Target/RegisterCont

[Lldb-commits] [lldb] [lldb/aarch64] Fix unwinding when signal interrupts a leaf function (PR #91321)

[Pavel Labath via lldb-commits]

labath wrote:

So, it took some effort, but I managed to reproduce the problem and figure out 
what's going on. You can find my analysis on 
https://github.com/llvm/llvm-project/pull/92503

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

[Lldb-commits] [lldb] [lldb] Fixed the TestCompletion test running on a remote target (PR #92281)

[Pavel Labath via lldb-commits]

@@ -107,9 +107,20 @@ def test_process_unload(self):
 self, "// Break here", lldb.SBFileSpec("main.cpp")
 )
 err = lldb.SBError()
-self.process().LoadImage(
-lldb.SBFileSpec(self.getBuildArtifact("libshared.so")), err
-)
+if lldb.remote_platform:
+self.process().LoadImage(
+lldb.SBFileSpec(self.getBuildArtifact("libshared.so")),
+lldb.SBFileSpec(
+lldbutil.append_to_process_working_directory(self, 
"libshared.so"),
+False,
+),
+err,
+)
+else:
+self.process().LoadImage(
+lldb.SBFileSpec(self.getBuildArtifact("libshared.so")),
+err,
+)

labath wrote:

Unfortunately, this ends up modifying the source tree. I'm going to revert this 
back to the intermediate version.

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

[Lldb-commits] [lldb] b27eb0a - [lldb] Avoid modifying the source tree in TestCompletion.py

[Pavel Labath via lldb-commits]

Author: Pavel Labath
Date: 2024-05-17T07:33:26Z
New Revision: b27eb0ae8280675fc8fb249d39f1ccafa3ee2187

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

LOG: [lldb] Avoid modifying the source tree in TestCompletion.py

This was a side-effect of the "optimization" in #92281. Deoptimize the
code slightly.

Added: 


Modified: 
lldb/test/API/functionalities/completion/TestCompletion.py

Removed: 




diff  --git a/lldb/test/API/functionalities/completion/TestCompletion.py 
b/lldb/test/API/functionalities/completion/TestCompletion.py
index 63842487fc338..15aeaf8d0e897 100644
--- a/lldb/test/API/functionalities/completion/TestCompletion.py
+++ b/lldb/test/API/functionalities/completion/TestCompletion.py
@@ -108,15 +108,17 @@ def test_process_unload(self):
 )
 err = lldb.SBError()
 local_spec = lldb.SBFileSpec(self.getBuildArtifact("libshared.so"))
-remote_spec = (
-lldb.SBFileSpec(
-lldbutil.append_to_process_working_directory(self, 
"libshared.so"),
-False,
+if lldb.remote_platform:
+self.process().LoadImage(
+local_spec,
+lldb.SBFileSpec(
+lldbutil.append_to_process_working_directory(self, 
"libshared.so"),
+False,
+),
+err,
 )
-if lldb.remote_platform
-else lldb.SBFileSpec()
-)
-self.process().LoadImage(local_spec, remote_spec, err)
+else:
+self.process().LoadImage(local_spec, err)
 self.assertSuccess(err)
 
 self.complete_from_to("process unload ", "process unload 0")



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

[Lldb-commits] [lldb] [lldb-dap] Added "port" property to vscode "attach" command. (PR #91570)

[Pavel Labath via lldb-commits]

https://github.com/labath requested changes to this pull request.

FWIW, I think this feature would be more useful and easier to implement if 
there was just a single setting called "connection url" or something, which 
accepted all of the usual lldb connection urls (unix-abstract-connect://, 
listen://, ...).

Since a simple tcp port connection is definitely going to be the most commonly 
used connection, you can, if you want, treat a simple number (or `:number`) as 
an alias to `connect://localhost:number`. lldb-server does something similar.

PS: I'm clicking request changes because I don't believe the test for the 
feature can go in in this form. I don't consider myself an owner for the rest, 
so you can consider my comments as suggestions.

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

[Lldb-commits] [lldb] [lldb-dap] Added "port" property to vscode "attach" command. (PR #91570)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [lldb-dap] Added "port" property to vscode "attach" command. (PR #91570)

[Pavel Labath via lldb-commits]

@@ -96,6 +96,7 @@
 #define LLDB_INVALID_QUEUE_ID 0
 #define LLDB_INVALID_CPU_ID UINT32_MAX
 #define LLDB_INVALID_WATCHPOINT_RESOURCE_ID UINT32_MAX
+#define LLDB_INVALID_PORT_NUMBER 0

labath wrote:

Port numbers aren't an lldb invention, so I don't think we should be putting 
this into the lldb's public (and forever immutable) API.

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

[Lldb-commits] [lldb] [lldb-dap] Added "port" property to vscode "attach" command. (PR #91570)

[Pavel Labath via lldb-commits]

@@ -0,0 +1,146 @@
+"""
+Test lldb-dap "port" configuration to "attach" request
+"""
+
+
+import dap_server
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test import lldbplatformutil
+import lldbgdbserverutils
+import lldbdap_testcase
+import os
+import shutil
+import subprocess
+import tempfile
+import threading
+import time
+import sys
+
+
+class TestDAP_attachByPortNum(lldbdap_testcase.DAPTestCaseBase):
+def runTargetProgramOnPort(self, port=None, program=None):
+server_tool = None
+if lldbplatformutil.getPlatform() == "linux":
+server_tool = lldbgdbserverutils.get_lldb_server_exe()
+if server_tool is None:
+self.dap_server.request_disconnect(terminateDebuggee=True)
+self.assertIsNotNone(server_tool, "lldb-server not found.")
+server_tool += " g localhost:" + port + " "
+elif lldbplatformutil.getPlatform() == "macosx":
+server_tool = lldbgdbserverutils.get_debugserver_exe()
+if server_tool is None:
+self.dap_server.request_disconnect(terminateDebuggee=True)
+self.assertIsNotNone(server_tool, "debugserver not found.")
+server_tool += " --listen localhost:" + port + " "
+
+self.process = subprocess.Popen(
+[server_tool + program],
+shell=True,
+stdin=subprocess.PIPE,
+stdout=subprocess.PIPE,
+stderr=subprocess.PIPE,
+)
+
+return self.process
+
+def set_and_hit_breakpoint(self, continueToExit=True):
+source = "main.c"
+main_source_path = os.path.join(os.getcwd(), source)
+breakpoint1_line = line_number(main_source_path, "// breakpoint 1")
+lines = [breakpoint1_line]
+# Set breakpoint in the thread function so we can step the threads
+breakpoint_ids = self.set_source_breakpoints(main_source_path, lines)
+self.assertEqual(
+len(breakpoint_ids), len(lines), "expect correct number of 
breakpoints"
+)
+self.continue_to_breakpoints(breakpoint_ids)
+if continueToExit:
+self.continue_to_exit()
+
+@skipIfWindows
+@skipIfNetBSD  # Hangs on NetBSD as well
+@skipIfRemote
+def test_by_port(self):
+"""
+Tests attaching to a process by port.
+"""
+self.build_and_create_debug_adaptor()
+program = self.getBuildArtifact("a.out")
+
+port = "2345"
+self.process = self.runTargetProgramOnPort(port=port, program=program)
+pid = self.process.pid
+response = self.attach(program=program, port=int(port), 
sourceInitFile=True)
+self.set_and_hit_breakpoint(continueToExit=True)
+self.process.kill()
+
+@skipIfWindows
+@skipIfNetBSD  # Hangs on NetBSD as well
+@skipIfRemote
+def test_by_port_and_pid(self):
+"""
+Tests attaching to a process by process ID and port number.
+"""
+self.build_and_create_debug_adaptor()
+program = self.getBuildArtifact("a.out")
+
+port = "2345"

labath wrote:

That's definitely not enough, and it's guaranteed to make the test flaky and/or 
environment sensitive. Both lldb-server and gdb support race-free port 
allocations by choosing the ports themselves letting the caller know of the 
actual chosen port.

Writing this logic in a way that works across server implementations and 
operating systems is not easy, but we already have the code (several in fact, 
but I'd recommend reusing the implementation in  
`test/API/tools/lldb-server/commandline/TestGdbRemoteConnection.py`).

As an alternative, since what you really just want to test is that the 
connection is made, you could consider using the mock gdb server implementation 
in `test/API/functionalities/gdb_remote_client/`. That way, it will be you (the 
python code) who's opening the ports, and there will again be no races.

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

[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target (PR #92413)

[Pavel Labath via lldb-commits]

@@ -52,6 +52,9 @@ def test_attach_with_vAttachWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
+if self._run_args:
+self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])

labath wrote:

Please do this inside `_set_up_inferior`, before assigning to `_run_args`

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

[Lldb-commits] [lldb] [lldb] Fixed the DAP tests in case of a remote target (PR #92416)

[Pavel Labath via lldb-commits]

labath wrote:

Are *all* lldb-dap tests not compatible with running remotely? If so, then 
instead of annotating them individually, we could tag them all with some "dap" 
category (if they're not already) and then automatically skip that category 
when running remotely.

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #92328)

[Pavel Labath via lldb-commits]

@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE &die,
 
   if (!die)
 return false;
+  ParsedDWARFTypeAttributes attrs(die);

labath wrote:

> Probably not, the `DWARFAttributes` object is large, 336 bytes.

I think that would be very wasteful, since we're just accessing these 
attributes once (well, maybe twice). After we've constructed the type, we 
should never need to look at them again, as all the information has been 
translated to the clang ast.

> This extra check was added in https://github.com/llvm/llvm-project/pull/91799 
> to ensure we don't accidentally parse declaration DIE

How exactly do we get here in that case? Presumably we still go through 
ParseTypesFromDWARF (where this property is checked already), is that right? 
Could we make a note somewhere (perhaps by putting a fake/invalid DIE into the 
type-to-die map) that the die is not a definition?

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

[Lldb-commits] [lldb] 33bf08e - [lldb-dap] Correctly detect alias commands with arguments in repl (#92137)

[via lldb-commits]

Author: Pavel Labath
Date: 2024-05-17T11:24:20+02:00
New Revision: 33bf08ec36efc2fc2df8217eddd751cef9bc6be6

URL: 
https://github.com/llvm/llvm-project/commit/33bf08ec36efc2fc2df8217eddd751cef9bc6be6
DIFF: 
https://github.com/llvm/llvm-project/commit/33bf08ec36efc2fc2df8217eddd751cef9bc6be6.diff

LOG: [lldb-dap] Correctly detect alias commands with arguments in repl (#92137)

ResolveCommand will not succeed for an alias command with arguments, and
the code wasn't providing any. Replace that with explicit query(ies) for
the existence of a command with the given name.

Added: 
lldb/test/API/tools/lldb-dap/repl-mode/Makefile
lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
lldb/test/API/tools/lldb-dap/repl-mode/main.cpp

Modified: 
lldb/tools/lldb-dap/DAP.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-dap/repl-mode/Makefile 
b/lldb/test/API/tools/lldb-dap/repl-mode/Makefile
new file mode 100644
index 0..8b20bcb05
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules

diff  --git 
a/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py 
b/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
new file mode 100644
index 0..7c77fc8541b93
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/TestDAP_repl_mode_detection.py
@@ -0,0 +1,55 @@
+"""
+Test lldb-dap repl mode detection
+"""
+
+import lldbdap_testcase
+import dap_server
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+
+
+class TestDAP_repl_mode_detection(lldbdap_testcase.DAPTestCaseBase):
+def assertEvaluate(self, expression, regex):
+self.assertRegex(
+self.dap_server.request_evaluate(expression, 
context="repl")["body"][
+"result"
+],
+regex,
+)
+
+def test_completions(self):
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+source = "main.cpp"
+breakpoint1_line = line_number(source, "// breakpoint 1")
+breakpoint2_line = line_number(source, "// breakpoint 2")
+
+self.set_source_breakpoints(source, [breakpoint1_line, 
breakpoint2_line])
+
+self.assertEvaluate(
+"`command regex user_command s/^$/platform/", r"\(lldb\) command 
regex"
+)
+self.assertEvaluate(
+"`command alias alias_command platform", r"\(lldb\) command alias"
+)
+self.assertEvaluate(
+"`command alias alias_command_with_arg platform select --sysroot 
%1 remote-linux",
+r"\(lldb\) command alias",
+)
+
+self.continue_to_next_stop()
+self.assertEvaluate("user_command", "474747")
+self.assertEvaluate("alias_command", "474747")
+self.assertEvaluate("alias_command_with_arg", "474747")
+self.assertEvaluate("platform", "474747")
+
+self.continue_to_next_stop()
+platform_help_needle = "Commands to manage and create platforms"
+self.assertEvaluate("user_command", platform_help_needle)
+self.assertEvaluate("alias_command", platform_help_needle)
+self.assertEvaluate(
+"alias_command_with_arg " + self.getBuildDir(), "Platform: 
remote-linux"
+)
+self.assertEvaluate("platform", platform_help_needle)

diff  --git a/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp 
b/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp
new file mode 100644
index 0..52561d3471abf
--- /dev/null
+++ b/lldb/test/API/tools/lldb-dap/repl-mode/main.cpp
@@ -0,0 +1,15 @@
+void noop() {}
+
+void fun() {
+  int user_command = 474747;
+  int alias_command = 474747;
+  int alias_command_with_arg = 474747;
+  int platform = 474747; // built-in command
+  noop();// breakpoint 1
+}
+
+int main() {
+  fun();
+  noop(); // breakpoint 2
+  return 0;
+}

diff  --git a/lldb/tools/lldb-dap/DAP.cpp b/lldb/tools/lldb-dap/DAP.cpp
index 55ff1493c1011..c7eb3db4304a9 100644
--- a/lldb/tools/lldb-dap/DAP.cpp
+++ b/lldb/tools/lldb-dap/DAP.cpp
@@ -14,6 +14,7 @@
 
 #include "DAP.h"
 #include "LLDBUtils.h"
+#include "lldb/API/SBCommandInterpreter.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/FormatVariadic.h"
 
@@ -405,9 +406,10 @@ ExpressionContext 
DAP::DetectExpressionContext(lldb::SBFrame frame,
 std::pair token =
 llvm::getToken(expression);
 std::string term = token.first.str();
-lldb::SBCommandReturnObject result;
-debugger.GetCommandInterpreter().ResolveCommand(term.c_str(), result);
-bool term_is_command = result.Succeeded();
+lldb::SBCommandInterpreter interpreter = debugger.GetCommandInterpreter();
+bool term_is_command = interpreter.CommandExists(term.c_str()) ||
+   

[Lldb-commits] [lldb] [lldb-dap] Correctly detect alias commands with arguments in repl (PR #92137)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] [lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (PR #77026)

[Pavel Labath via lldb-commits]

labath wrote:

Thanks for checking this out.

> I just checked and I'm not seeing the hover's in the same format as they were 
> when I made the pull request. The expression context should still have the 
> expanded forms though for example:
>  src="https://private-user-images.githubusercontent.com/22535/331420652-28db4adc-d488-44ff-8d99-78966e0e0e05.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTU5NDA1NTEsIm5iZiI6MTcxNTk0MDI1MSwicGF0aCI6Ii8yMjUzNS8zMzE0MjA2NTItMjhkYjRhZGMtZDQ4OC00NGZmLThkOTktNzg5NjZlMGUwZTA1LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA1MTclMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNTE3VDEwMDQxMVomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTZmMzA1YmZmMmI3NzBjNDgwNzI2OGIwZmMwYWNhYWMwMjQ1Mzg0MmJlMWViMzVjNjY0MGUzZDA3NDZjMzBiZjQmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.h5ENxzEWOpUxdFomZps6rWm7-J906W-3Le0mcRcYdUY";>
> 

I see. I think it makes sense to show this expanded view in the debug console 
view. However, it does not appear to be useful for the hover view, and it's 
slowing things down significantly (for one particular probobuf variable, this 
increased the hover time from <1sec to ~6-7 seconds).

Would you be ok (both of you) with limiting the scope of this patch to the 
"repl" context?

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -406,6 +406,36 @@ class Process : public 
std::enable_shared_from_this,
   lldb::StateType state);
   } Notifications;
 
+  class ProcessMemoryIterator {

labath wrote:

AFAICT, this isn't necessary anymore. If you think it's useful, you can make it 
a separate patch.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

https://github.com/labath commented:

This looks much better, though, after looking at this closer, I don't think 
it's necessary to reimplement the elf parsing code. We already have all the 
necessary data structures for parsing notes in the core file itself, and it 
looks like it would be fairly easy to reuse them for this purpose as well.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,
+ const uint32_t type) {
+  if (!IsElf(address))
+return std::nullopt;
+  const uint32_t addr_size = GetAddressByteSize();
+  const lldb::offset_t ehdr_phoff_offset = ELFOFFSETOF(Ehdr, e_phoff);
+  const lldb::offset_t ehdr_phentsize_offset = ELFOFFSETOF(Ehdr, e_phentsize);
+  const lldb::offset_t ehdr_phnum_offset = ELFOFFSETOF(Ehdr, e_phnum);
+  const size_t elf_header_size = addr_size == 4 ? sizeof(llvm::ELF::Elf32_Ehdr)
+: 
sizeof(llvm::ELF::Elf64_Ehdr);
+
+  unsigned char buf[4096];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, elf_header_size, error);
+  DataExtractor data(buf, 4096, GetByteOrder(), addr_size);
+  lldb::offset_t offset = ehdr_phoff_offset;
+  lldb::offset_t phoff = data.GetAddress(&offset);
+
+  offset = ehdr_phentsize_offset;
+  lldb::offset_t phentsize = data.GetU16(&offset);
+  offset = ehdr_phnum_offset;
+  lldb::offset_t phnum = data.GetU16(&offset);
+
+  Section_Note note;
+  const lldb::addr_t ph_addr = address + phoff;
+
+  for (unsigned int i = 0; i < phnum; ++i) {
+byte_read = ReadMemory(ph_addr + i * phentsize, buf, phentsize, error);
+if (byte_read != phentsize)
+  break;
+offset = 0;
+uint32_t p_type = data.GetU32(&offset);
+if (p_type != llvm::ELF::PT_NOTE)
+  continue;
+offset = ELFOFFSETOF(Phdr, p_vaddr);
+lldb::addr_t p_vaddr = data.GetAddress(&offset);
+offset = ELFOFFSETOF(Phdr, p_memsz);
+lldb::addr_t p_memsz = data.GetAddress(&offset);

labath wrote:

Similarly, you can use `ELFProgramHeader::Parse` for this bit.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,

labath wrote:

Please give this a more specific name (to say what kind of note its searching 
for and where). An uninformed reader would think this is searching for a note 
in the core file itself.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -158,6 +165,16 @@ class ProcessElfCore : public 
lldb_private::PostMortemProcess {
   // Returns number of thread contexts stored in the core file
   uint32_t GetNumThreadContexts();
 
+  // Populate gnu uuid for each NT_FILE entry
+  void UpdateBuildIdForNTFileEntries();
+
+  // Returns the value of certain type of note of a given start address
+  std::optional FindNote(const lldb::addr_t address,

labath wrote:

`const` on a value parameter (pointer and reference parameters are of course 
different) declaration don't actually do anything, and I don't believe we 
usually use them.

If you really want to you can still make them `const` in [the function 
definition](https://godbolt.org/z/PxM739P84) even if they're not const in the 
header (though we usually don't do that either).

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,
+ const uint32_t type) {
+  if (!IsElf(address))
+return std::nullopt;
+  const uint32_t addr_size = GetAddressByteSize();
+  const lldb::offset_t ehdr_phoff_offset = ELFOFFSETOF(Ehdr, e_phoff);
+  const lldb::offset_t ehdr_phentsize_offset = ELFOFFSETOF(Ehdr, e_phentsize);
+  const lldb::offset_t ehdr_phnum_offset = ELFOFFSETOF(Ehdr, e_phnum);
+  const size_t elf_header_size = addr_size == 4 ? sizeof(llvm::ELF::Elf32_Ehdr)
+: 
sizeof(llvm::ELF::Elf64_Ehdr);
+
+  unsigned char buf[4096];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, elf_header_size, error);
+  DataExtractor data(buf, 4096, GetByteOrder(), addr_size);
+  lldb::offset_t offset = ehdr_phoff_offset;
+  lldb::offset_t phoff = data.GetAddress(&offset);
+
+  offset = ehdr_phentsize_offset;
+  lldb::offset_t phentsize = data.GetU16(&offset);
+  offset = ehdr_phnum_offset;
+  lldb::offset_t phnum = data.GetU16(&offset);

labath wrote:

Reuse the existing `ELFHeader` class for this. I.e., read the necessary amount 
of bytes (you can just always read `sizeof(Elf64_Ehdr)` as that's larger) into 
a DataExtractor and call `header.Parse(extractor, 0)`.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -271,6 +282,17 @@ Status ProcessElfCore::DoLoadCore() {
   return error;
 }
 
+void ProcessElfCore::UpdateBuildIdForNTFileEntries() {
+  if (!m_nt_file_entries.empty()) {

labath wrote:

Any specific reason doing this as a separate pass (and not from inside parsing 
loop on line 936)?

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Pavel Labath via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,
+ const uint32_t type) {
+  if (!IsElf(address))
+return std::nullopt;
+  const uint32_t addr_size = GetAddressByteSize();
+  const lldb::offset_t ehdr_phoff_offset = ELFOFFSETOF(Ehdr, e_phoff);
+  const lldb::offset_t ehdr_phentsize_offset = ELFOFFSETOF(Ehdr, e_phentsize);
+  const lldb::offset_t ehdr_phnum_offset = ELFOFFSETOF(Ehdr, e_phnum);
+  const size_t elf_header_size = addr_size == 4 ? sizeof(llvm::ELF::Elf32_Ehdr)
+: 
sizeof(llvm::ELF::Elf64_Ehdr);
+
+  unsigned char buf[4096];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, elf_header_size, error);
+  DataExtractor data(buf, 4096, GetByteOrder(), addr_size);
+  lldb::offset_t offset = ehdr_phoff_offset;
+  lldb::offset_t phoff = data.GetAddress(&offset);
+
+  offset = ehdr_phentsize_offset;
+  lldb::offset_t phentsize = data.GetU16(&offset);
+  offset = ehdr_phnum_offset;
+  lldb::offset_t phnum = data.GetU16(&offset);
+
+  Section_Note note;
+  const lldb::addr_t ph_addr = address + phoff;
+
+  for (unsigned int i = 0; i < phnum; ++i) {
+byte_read = ReadMemory(ph_addr + i * phentsize, buf, phentsize, error);
+if (byte_read != phentsize)
+  break;
+offset = 0;
+uint32_t p_type = data.GetU32(&offset);
+if (p_type != llvm::ELF::PT_NOTE)
+  continue;
+offset = ELFOFFSETOF(Phdr, p_vaddr);
+lldb::addr_t p_vaddr = data.GetAddress(&offset);
+offset = ELFOFFSETOF(Phdr, p_memsz);
+lldb::addr_t p_memsz = data.GetAddress(&offset);
+
+byte_read = ReadMemory(p_vaddr, buf, p_memsz, error);
+if (byte_read != p_memsz)
+  continue;
+offset = 0;
+while (
+offset < p_memsz &&
+data.GetU32(&offset, ¬e, sizeof(Section_Note) / sizeof(uint32_t))) {
+  if (note.namesz == 4 && note.type == type) {
+const char *name = data.GetCStr(&offset);
+if (name && strcmp("GNU", name) == 0)
+  return UUID(
+  llvm::ArrayRef(buf + offset, note.descsz /*byte 
size*/));
+  }
+  offset += note.namesz + note.descsz;
+}

labath wrote:

And `parseSegment` for this (despite the generic name, this is really for 
parsing note segments, maybe you could rename it while you're in here).

https://github.com/llvm/llvm-project/pull/92492
___
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] [compiler-rt] [lldb] [llvm] [mlir] [openmp] [polly] fix(python): fix comparison to None (PR #91857)

[Oleksandr Alex Zinenko via lldb-commits]

ftynse wrote:

> 10 separate commits/PRs for the same exact sed costs more in commit noise 
> (and effort on the part of @e-kwsm) than one solid, patient, review here

Not unless you subscribe only to a subproject. FWIW, I'm not comfortable 
blanket approving changes, however trivial, to subprojects I'm not actively 
working on, and I suspect most folks here are not. Subprojects may have some 
ongoing work that will be disrupted or reasons why they chose the suboptimal 
implementation.

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

[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target (PR #92413)

[Dmitry Vasilyev via lldb-commits]

https://github.com/slydiman updated 
https://github.com/llvm/llvm-project/pull/92413

>From d88cc6d992e1f753066aa5dccaa510d8a0a35b94 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Thu, 16 May 2024 19:18:21 +0400
Subject: [PATCH 1/2] [lldb] Fixed the test TestGdbRemoteAttachWait running on
 a remote target

Install `_exe_to_attach` to a remote target if necessary.
---
 .../lldb-server/attach-wait/TestGdbRemoteAttachWait.py   | 9 +
 1 file changed, 9 insertions(+)

diff --git 
a/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py 
b/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
index f4c31fe2f5c07..a8333210a72b1 100644
--- a/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
+++ b/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
@@ -52,6 +52,9 @@ def test_attach_with_vAttachWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
+if self._run_args:
+self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])
+
 # Launch the first inferior (we shouldn't attach to this one).
 self._launch_and_wait_for_init()
 
@@ -101,6 +104,9 @@ def test_launch_before_attach_with_vAttachOrWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
+if self._run_args:
+self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])
+
 inferior = self._launch_and_wait_for_init()
 
 # Add attach packets.
@@ -141,6 +147,9 @@ def test_launch_after_attach_with_vAttachOrWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
+if self._run_args:
+self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])
+
 
self.test_sequence.add_log_lines([self._attach_packet("vAttachOrWait")], True)
 # Run the stream until attachWait.
 context = self.expect_gdbremote_sequence()

>From 1f329275f90c0be3ecf73f3e9e3c816439596116 Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Fri, 17 May 2024 16:26:57 +0400
Subject: [PATCH 2/2] Moved install_to_target() to _set_up_inferior().

---
 .../attach-wait/TestGdbRemoteAttachWait.py | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git 
a/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py 
b/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
index a8333210a72b1..84aab9c969aa4 100644
--- a/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
+++ b/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
@@ -17,7 +17,10 @@ def _set_up_inferior(self):
 # Use a shim to ensure that the process is ready to be attached 
from
 # the get-go.
 self._exe_to_run = "shim"
-self._run_args = [self.getBuildArtifact(self._exe_to_attach)]
+self._exe_to_attach = lldbutil.install_to_target(
+self, self.getBuildArtifact(self._exe_to_attach)
+)
+self._run_args = [self._exe_to_attach]
 self.build(dictionary={"EXE": self._exe_to_run, "CXX_SOURCES": 
"shim.cpp"})
 else:
 self._exe_to_run = self._exe_to_attach
@@ -52,9 +55,6 @@ def test_attach_with_vAttachWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
-if self._run_args:
-self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])
-
 # Launch the first inferior (we shouldn't attach to this one).
 self._launch_and_wait_for_init()
 
@@ -104,9 +104,6 @@ def test_launch_before_attach_with_vAttachOrWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
-if self._run_args:
-self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])
-
 inferior = self._launch_and_wait_for_init()
 
 # Add attach packets.
@@ -147,9 +144,6 @@ def test_launch_after_attach_with_vAttachOrWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
-if self._run_args:
-self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])
-
 
self.test_sequence.add_log_lines([self._attach_packet("vAttachOrWait")], True)
 # Run the stream until attachWait.
 context = self.expect_gdbremote_sequence()

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

[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target (PR #92413)

[Dmitry Vasilyev via lldb-commits]

@@ -52,6 +52,9 @@ def test_attach_with_vAttachWait(self):
 server = self.connect_to_debug_monitor()
 self.do_handshake()
 
+if self._run_args:
+self._run_args[0] = lldbutil.install_to_target(self, 
self._run_args[0])

slydiman wrote:

I have updated the patch. Thanks.

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

[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target (PR #92413)

[Pavel Labath via lldb-commits]

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

Thanks.

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

[Lldb-commits] [lldb] [lldb] Fixed the DAP tests in case of a remote target (PR #92416)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

That's a great idea. There's no such `dap` category at the moment, but it would 
be nice if such category is created as part of the ongoing lldb-dap test fixes.

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

[Lldb-commits] [lldb] [lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (PR #77026)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

I'm okay with anything that ensures hovering is fast.

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

[Lldb-commits] [lldb] [lldb-dap] Added "port" property to vscode "attach" command. (PR #91570)

[Walter Erquinigo via lldb-commits]

walter-erquinigo wrote:

Thanks, @labath , for chiming in. I actually agree with all your points.

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

[Lldb-commits] [lldb] [llvm] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #91880)

[Youngsuk Kim via lldb-commits]

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

[Lldb-commits] [lldb] [llvm] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #91880)

[Youngsuk Kim via lldb-commits]

https://github.com/JOE1994 requested changes to this pull request.

* The PR contains irrelevant changes to `X86` codegen.
* Author of the commit shows up as another contributor.

It seems like the author of this PR did a `git commit --amend`
on top of e586556e375fc5c4f7e76b5c299cb981f2016108 to add new changes.

Please update the branch to address these issues.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Kevin Frei via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,

kevinfrei wrote:

I'd suggest instead, implement support for the Note section in the same fashion 
as the other ELF components, with a "parse" method and the like (check out 
ThreadElfCore.h) and integrated it into the top level loop, same as the other 
Program Header structures.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Kevin Frei via lldb-commits]

@@ -271,6 +282,17 @@ Status ProcessElfCore::DoLoadCore() {
   return error;
 }
 
+void ProcessElfCore::UpdateBuildIdForNTFileEntries() {
+  if (!m_nt_file_entries.empty()) {

kevinfrei wrote:

I'd suggest adding it to that pass as well, though it will be a little bit 
messier, as NT_PRPSINFO and NT_GNU_BUILD_ID have the same values, so they 
depend on the Name field (CORE and GNU, respectively...). Do a check for the 
GNU name at the very top (line 902ish?) and handle NT_GNU_BUILD_ID's before the 
rest of that loop body, or dealing with PRPSINFO logic will get much messier...

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Kevin Frei via lldb-commits]

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Kevin Frei via lldb-commits]

https://github.com/kevinfrei requested changes to this pull request.


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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Kevin Frei via lldb-commits]

@@ -117,6 +117,13 @@ class ProcessElfCore : public 
lldb_private::PostMortemProcess {
 lldb::addr_t end;
 lldb::addr_t file_ofs;
 std::string path;
+lldb_private::UUID uuid; //.note.gnu.build-id
+  };
+
+  struct Section_Note {
+uint32_t namesz;
+uint32_t descsz;
+uint32_t type;

kevinfrei wrote:

Move this to the ThreadElfCore.h header and add a 'parse' method to it, so the 
UUID is populated much like the PRPSINFO data and other useful info from the 
coredump.

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

[Lldb-commits] [lldb] [lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (PR #77026)

[John Harrison via lldb-commits]

ashgti wrote:

Sounds good to me

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

[Lldb-commits] [lldb] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #92565)

[via lldb-commits]

https://github.com/aabhinavg created 
https://github.com/llvm/llvm-project/pull/92565

Summary of Changes:

Replaced the ineffective call to `substr` with a more efficient use of `resize` 
to truncate the string.
Adjusted the code to use 'resize' instead of 'substr' for better performance 
and readability.
Removed unwanted file from the previous commit.
Fixes: #91209 

>From 13fefb6846b6641900843c37746b03140063a955 Mon Sep 17 00:00:00 2001
From: aabhinavg 
Date: Fri, 17 May 2024 21:17:51 +0530
Subject: [PATCH] removed unwanted file

---
 lldb/source/Core/Debugger.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 9951fbcd3e7c3..70303173925e3 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -2067,7 +2067,7 @@ void Debugger::HandleProgressEvent(const lldb::EventSP 
&event_sp) {
   const uint32_t term_width = GetTerminalWidth();
   const uint32_t ellipsis = 3;
   if (message.size() + ellipsis >= term_width)
-message = message.substr(0, term_width - ellipsis);
+message.resize(message.size() - ellipsis);
 
   const bool use_color = GetUseColor();
   llvm::StringRef ansi_prefix = GetShowProgressAnsiPrefix();

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

[Lldb-commits] [lldb] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #92565)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (aabhinavg)


Changes

Summary of Changes:

Replaced the ineffective call to `substr` with a more efficient use of `resize` 
to truncate the string.
Adjusted the code to use 'resize' instead of 'substr' for better performance 
and readability.
Removed unwanted file from the previous commit.
Fixes: #91209 

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


1 Files Affected:

- (modified) lldb/source/Core/Debugger.cpp (+1-1) 


``diff
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 9951fbcd3e7c3..70303173925e3 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -2067,7 +2067,7 @@ void Debugger::HandleProgressEvent(const lldb::EventSP 
&event_sp) {
   const uint32_t term_width = GetTerminalWidth();
   const uint32_t ellipsis = 3;
   if (message.size() + ellipsis >= term_width)
-message = message.substr(0, term_width - ellipsis);
+message.resize(message.size() - ellipsis);
 
   const bool use_color = GetUseColor();
   llvm::StringRef ansi_prefix = GetShowProgressAnsiPrefix();

``




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

[Lldb-commits] [lldb] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #92565)

[via lldb-commits]

github-actions[bot] wrote:

⚠️ We detected that you are using a GitHub private e-mail address to contribute 
to the repo. Please turn off [Keep my email addresses 
private](https://github.com/settings/emails) setting in your account. See 
[LLVM 
Discourse](https://discourse.llvm.org/t/hidden-emails-on-github-should-we-do-something-about-it)
 for more information.

https://github.com/llvm/llvm-project/pull/92565
___
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] [compiler-rt] [lldb] [llvm] [mlir] [openmp] [polly] fix(python): fix comparison to None (PR #91857)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> It's a `sed s/== None/is None/g` - what is there to review? 10 separate 
> commits/PRs for the same exact `sed` costs more in commit noise (and effort 
> on the part of @e-kwsm) than one solid, patient, review here.

In addition to what @ftynse said above, the `sed` might not be the right thing 
in the first place (e.g. #91858). 

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

[Lldb-commits] [lldb] Reapply [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (PR #92328)

[Zequan Wu via lldb-commits]

@@ -2306,6 +2345,11 @@ bool DWARFASTParserClang::CompleteTypeFromDWARF(const 
DWARFDIE &die,
 
   if (!die)
 return false;
+  ParsedDWARFTypeAttributes attrs(die);

ZequanWu wrote:

> How exactly do we get here in that case?

>From https://github.com/llvm/llvm-project/pull/90663#issuecomment-2105194128, 
>.debug_names somehow contains entries that are declarations. This causes 
>`SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext` to return a type 
>created from declaration when searching for definition. 

A simple idea I have in mind is to make the `GetForwardDeclCompilerTypeToDIE`'s 
value type to a pair `{DIERef, bool}`, and the bool indicate if this is a 
definition or not. So we know that info without extra attribute parsing. How do 
you think?

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

[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)

[Michael Buch via lldb-commits]

Michael137 wrote:

I attached to clang and printed an expression. That resulted in 16801 calls to 
`Progress::Increment`, all of which I'm guessing translate to event broadcasts. 
I collected some timing numbers:
```
https://github.com/llvm/llvm-project/assets/14071464/97333f8a-2e35-47c9-8cd0-d610daa077fd";>
```

So across the various scenarios i tested the slowdown is somewhere between 
10-90 ms on average.

> I'd expect that a one of these operations (parsing/importing one type) would 
> be pretty fast, and that the whole process takes so long simply because 
> performing a very large number of these ops.

@labath Mostly that's true. Occasionally these operations can take longer if we 
end up searching for types/functions across multiple object files (especially 
with https://github.com/apple/llvm-project/pull/8222). We could certainly 
consider some sort of rate limiting here. Or maybe find a better place to 
report progress on?

> Anyway, if the code is recursive, we might need to do something like we did 
> for Swift, with one top-level event and callback that updates the details.

@JDevlieghere @adrian-prantl are there plans to change the presentation layer 
to prevent this kind of shadowing in the future? Would be nice if all we needed 
to do was report progress, and not worry about other progress events in the 
debugger being in-flight

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

[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> @JDevlieghere @adrian-prantl are there plans to change the presentation layer 
> to prevent this kind of shadowing in the future? Would be nice if all we 
> needed to do was report progress, and not worry about other progress events 
> in the debugger being in-flight

No, on the terminal it works that way by design. Unless you switch to something 
that takes full control of your screen (like curses) there's no good way to 
display multiple progress events at the same time and not doing the shadowing 
(i.e. letting more recent progress events through) defeats the purpose of 
highlighting long running operations. 

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

[Lldb-commits] [lldb] d38ea8c - [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target (#92413)

[via lldb-commits]

Author: Dmitry Vasilyev
Date: 2024-05-17T20:14:09+04:00
New Revision: d38ea8c4c84be9496249098053599c24b87f1376

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

LOG: [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target 
(#92413)

Install `_exe_to_attach` to a remote target if necessary.

Added: 


Modified: 
lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py

Removed: 




diff  --git 
a/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py 
b/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
index f4c31fe2f5c07..84aab9c969aa4 100644
--- a/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
+++ b/lldb/test/API/tools/lldb-server/attach-wait/TestGdbRemoteAttachWait.py
@@ -17,7 +17,10 @@ def _set_up_inferior(self):
 # Use a shim to ensure that the process is ready to be attached 
from
 # the get-go.
 self._exe_to_run = "shim"
-self._run_args = [self.getBuildArtifact(self._exe_to_attach)]
+self._exe_to_attach = lldbutil.install_to_target(
+self, self.getBuildArtifact(self._exe_to_attach)
+)
+self._run_args = [self._exe_to_attach]
 self.build(dictionary={"EXE": self._exe_to_run, "CXX_SOURCES": 
"shim.cpp"})
 else:
 self._exe_to_run = self._exe_to_attach



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

[Lldb-commits] [lldb] [lldb] Fixed the test TestGdbRemoteAttachWait running on a remote target (PR #92413)

[Dmitry Vasilyev via lldb-commits]

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -1649,6 +1679,26 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Find a string within a memory region.
+  ///
+  /// This function searches for the string represented by the provided buffer

clayborg wrote:

change to:
```
  /// This function searches for the bytes represented by the provided buffer
```

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -1649,6 +1679,26 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Find a string within a memory region.

clayborg wrote:

Change to:
```
/// Find bytes within a memory range.

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -117,6 +117,13 @@ class ProcessElfCore : public 
lldb_private::PostMortemProcess {
 lldb::addr_t end;
 lldb::addr_t file_ofs;
 std::string path;
+lldb_private::UUID uuid; //.note.gnu.build-id
+  };
+
+  struct Section_Note {
+uint32_t namesz;
+uint32_t descsz;
+uint32_t type;

clayborg wrote:

or move it into ELFHeader.h and then add a parse method. We are using a ton of 
stuff already from ELFHeader.h, so we should follow that path

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,

clayborg wrote:

Maybe the name of `FindNoteInCoreMemory`?

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -33,12 +35,17 @@
 #include "Plugins/Process/elf-core/RegisterUtilities.h"
 #include "ProcessElfCore.h"
 #include "ThreadElfCore.h"
+#include "lldb/lldb-types.h"
 
 using namespace lldb_private;
 namespace ELF = llvm::ELF;
 
 LLDB_PLUGIN_DEFINE(ProcessElfCore)
 
+#define ELFOFFSETOF(T, M)  
\
+  addr_size == 4 ? offsetof(llvm::ELF::Elf32_##T, M)   
\
+ : offsetof(llvm::ELF::Elf64_##T, M)

clayborg wrote:

We should pass in `addr_size` here:
```
#define ELFOFFSETOF(type_name, member, addr_size) ...
```

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -1649,6 +1679,26 @@ class Process : public 
std::enable_shared_from_this,
 
   lldb::addr_t ReadPointerFromMemory(lldb::addr_t vm_addr, Status &error);
 
+  /// Find a string within a memory region.
+  ///
+  /// This function searches for the string represented by the provided buffer
+  /// within the memory range specified by the low and high addresses. It uses
+  /// a bad character heuristic to optimize the search process.
+  ///
+  /// \param[in] low The starting address of the memory region to be searched.
+  ///
+  /// \param[in] high The ending address of the memory region to be searched.
+  ///
+  /// \param[in] buffer A pointer to the buffer containing the string to be
+  /// searched.

clayborg wrote:

```
  /// \param[in] buffer A pointer to the buffer containing the bytes to be
  /// searched.
```

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,
+ const uint32_t type) {
+  if (!IsElf(address))
+return std::nullopt;
+  const uint32_t addr_size = GetAddressByteSize();
+  const lldb::offset_t ehdr_phoff_offset = ELFOFFSETOF(Ehdr, e_phoff);
+  const lldb::offset_t ehdr_phentsize_offset = ELFOFFSETOF(Ehdr, e_phentsize);
+  const lldb::offset_t ehdr_phnum_offset = ELFOFFSETOF(Ehdr, e_phnum);
+  const size_t elf_header_size = addr_size == 4 ? sizeof(llvm::ELF::Elf32_Ehdr)
+: 
sizeof(llvm::ELF::Elf64_Ehdr);
+
+  unsigned char buf[4096];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, elf_header_size, error);
+  DataExtractor data(buf, 4096, GetByteOrder(), addr_size);
+  lldb::offset_t offset = ehdr_phoff_offset;
+  lldb::offset_t phoff = data.GetAddress(&offset);
+
+  offset = ehdr_phentsize_offset;
+  lldb::offset_t phentsize = data.GetU16(&offset);
+  offset = ehdr_phnum_offset;
+  lldb::offset_t phnum = data.GetU16(&offset);

clayborg wrote:

header for the `ELFHeader` class is in: 
```
lldb/source/Plugins/ObjectFile/ELF/ELFHeader.h
```

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

[Lldb-commits] [lldb] Read and store gnu build id from loaded core file (PR #92492)

[Greg Clayton via lldb-commits]

@@ -983,6 +1005,73 @@ llvm::Error 
ProcessElfCore::ParseThreadContextsFromNoteSegment(
   }
 }
 
+bool ProcessElfCore::IsElf(const lldb::addr_t address) {
+  uint8_t buf[4];
+  Status error;
+  size_t byte_read = ReadMemory(address, buf, 4, error);
+  if (byte_read != 4)
+return false;
+  return elf::ELFHeader::MagicBytesMatch(buf);
+}
+
+std::optional ProcessElfCore::FindNote(const lldb::addr_t address,
+ const uint32_t type) {
+  if (!IsElf(address))
+return std::nullopt;
+  const uint32_t addr_size = GetAddressByteSize();
+  const lldb::offset_t ehdr_phoff_offset = ELFOFFSETOF(Ehdr, e_phoff);
+  const lldb::offset_t ehdr_phentsize_offset = ELFOFFSETOF(Ehdr, e_phentsize);
+  const lldb::offset_t ehdr_phnum_offset = ELFOFFSETOF(Ehdr, e_phnum);

clayborg wrote:

pass `addr_size` to the macro

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

[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)

[via lldb-commits]

https://github.com/royitaqi updated 
https://github.com/llvm/llvm-project/pull/90703

>From 0fd67e2de7e702ce6f7353845454ea7ff9f980d6 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Tue, 30 Apr 2024 21:35:49 -0700
Subject: [PATCH 01/18] Add SBCommandInterpreter::GetTranscript()

---
 lldb/include/lldb/API/SBCommandInterpreter.h | 12 +---
 lldb/source/API/SBCommandInterpreter.cpp |  7 ++-
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/lldb/include/lldb/API/SBCommandInterpreter.h 
b/lldb/include/lldb/API/SBCommandInterpreter.h
index ba2e049204b8e..d65f06d676f91 100644
--- a/lldb/include/lldb/API/SBCommandInterpreter.h
+++ b/lldb/include/lldb/API/SBCommandInterpreter.h
@@ -247,13 +247,13 @@ class SBCommandInterpreter {
lldb::SBStringList &matches,
lldb::SBStringList &descriptions);
 
-  /// Returns whether an interrupt flag was raised either by the SBDebugger - 
+  /// Returns whether an interrupt flag was raised either by the SBDebugger -
   /// when the function is not running on the RunCommandInterpreter thread, or
   /// by SBCommandInterpreter::InterruptCommand if it is.  If your code is 
doing
-  /// interruptible work, check this API periodically, and interrupt if it 
+  /// interruptible work, check this API periodically, and interrupt if it
   /// returns true.
   bool WasInterrupted() const;
-  
+
   /// Interrupts the command currently executing in the RunCommandInterpreter
   /// thread.
   ///
@@ -318,6 +318,12 @@ class SBCommandInterpreter {
 
   SBStructuredData GetStatistics();
 
+  /// Returns a list of handled commands, output and error. Each element in
+  /// the list is a dictionary with three keys: "command" (string), "output"
+  /// (list of strings) and optionally "error" (list of strings). Each string
+  /// in "output" and "error" is a line (without EOL characteres).
+  SBStructuredData GetTranscript();
+
 protected:
   friend class lldb_private::CommandPluginInterfaceImplementation;
 
diff --git a/lldb/source/API/SBCommandInterpreter.cpp 
b/lldb/source/API/SBCommandInterpreter.cpp
index 83c0951c56db6..242b3f8f09c48 100644
--- a/lldb/source/API/SBCommandInterpreter.cpp
+++ b/lldb/source/API/SBCommandInterpreter.cpp
@@ -150,7 +150,7 @@ bool SBCommandInterpreter::WasInterrupted() const {
 
 bool SBCommandInterpreter::InterruptCommand() {
   LLDB_INSTRUMENT_VA(this);
-  
+
   return (IsValid() ? m_opaque_ptr->InterruptCommand() : false);
 }
 
@@ -571,6 +571,11 @@ SBStructuredData SBCommandInterpreter::GetStatistics() {
   return data;
 }
 
+SBStructuredData SBCommandInterpreter::GetTranscript() {
+  LLDB_INSTRUMENT_VA(this);
+  return SBStructuredData();
+}
+
 lldb::SBCommand SBCommandInterpreter::AddMultiwordCommand(const char *name,
   const char *help) {
   LLDB_INSTRUMENT_VA(this, name, help);

>From a1c948ceabaccdc3407e0c4eae0ebc594a9b68b7 Mon Sep 17 00:00:00 2001
From: Roy Shi 
Date: Wed, 1 May 2024 13:45:47 -0700
Subject: [PATCH 02/18] Implement the new API

---
 .../lldb/Interpreter/CommandInterpreter.h | 12 +--
 lldb/include/lldb/Utility/StructuredData.h| 11 +++---
 lldb/source/API/SBCommandInterpreter.cpp  |  8 -
 .../source/Interpreter/CommandInterpreter.cpp | 21 ++-
 lldb/source/Utility/StructuredData.cpp| 35 +++
 5 files changed, 79 insertions(+), 8 deletions(-)

diff --git a/lldb/include/lldb/Interpreter/CommandInterpreter.h 
b/lldb/include/lldb/Interpreter/CommandInterpreter.h
index 70a55a77465bf..9474c41c0dced 100644
--- a/lldb/include/lldb/Interpreter/CommandInterpreter.h
+++ b/lldb/include/lldb/Interpreter/CommandInterpreter.h
@@ -22,6 +22,7 @@
 #include "lldb/Utility/Log.h"
 #include "lldb/Utility/StreamString.h"
 #include "lldb/Utility/StringList.h"
+#include "lldb/Utility/StructuredData.h"
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-private.h"
 
@@ -241,7 +242,7 @@ class CommandInterpreter : public Broadcaster,
 eCommandTypesAllThem = 0x  //< all commands
   };
 
-  // The CommandAlias and CommandInterpreter both have a hand in 
+  // The CommandAlias and CommandInterpreter both have a hand in
   // substituting for alias commands.  They work by writing special tokens
   // in the template form of the Alias command, and then detecting them when 
the
   // command is executed.  These are the special tokens:
@@ -576,7 +577,7 @@ class CommandInterpreter : public Broadcaster,
   void SetEchoCommentCommands(bool enable);
 
   bool GetRepeatPreviousCommand() const;
-  
+
   bool GetRequireCommandOverwrite() const;
 
   const CommandObject::CommandMap &GetUserCommands() const {
@@ -647,6 +648,7 @@ class CommandInterpreter : public Broadcaster,
   }
 
   llvm::json::Value GetStatistics();
+  StructuredData::ArraySP GetTranscript() const;
 
 protected:
   friend class Debugger;
@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster

[Lldb-commits] [lldb] [lldb] Added Debuginfod tests and fixed a couple issues (PR #92572)

[Kevin Frei via lldb-commits]

https://github.com/kevinfrei created 
https://github.com/llvm/llvm-project/pull/92572

Here we go with attempt #5.
Again, no changes to the LLDB code diffs that have been looked at several times.

For the tests, I added a `@skipIfCurlSupportMissing` annotation so that the 
Debuginfod mocked server stuff won't run, and I also disabled non-Linux/FreeBSD 
hosts altogether, as they fail for platform reasons on macOS and Windows. In 
addition, I updated the process for extracting the GNU BuildID to no create a 
target, per some feedback on the previous diff.

>From 8a544973fcdb0391f3342b6e6e44b4cf422d0429 Mon Sep 17 00:00:00 2001
From: Kevin Frei 
Date: Mon, 25 Mar 2024 08:23:47 -0700
Subject: [PATCH 01/12] Trying to deal with Linux AArch64 test failures :/

---
 .../SymbolVendor/ELF/SymbolVendorELF.cpp  |  18 ++
 .../API/debuginfod/Normal/TestDebuginfod.py   | 187 +
 .../SplitDWARF/TestDebuginfodDWP.py   | 196 ++
 3 files changed, 401 insertions(+)
 create mode 100644 lldb/test/API/debuginfod/Normal/TestDebuginfod.py
 create mode 100644 lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py

diff --git a/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp 
b/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
index b5fe35d71032a..a881218a56cef 100644
--- a/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
+++ b/lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp
@@ -44,6 +44,24 @@ llvm::StringRef 
SymbolVendorELF::GetPluginDescriptionStatic() {
  "executables.";
 }
 
+// If this is needed elsewhere, it can be exported/moved.
+static bool IsDwpSymbolFile(const lldb::ModuleSP &module_sp,
+const FileSpec &file_spec) {
+  DataBufferSP dwp_file_data_sp;
+  lldb::offset_t dwp_file_data_offset = 0;
+  // Try to create an ObjectFile from the file_spec.
+  ObjectFileSP dwp_obj_file = ObjectFile::FindPlugin(
+  module_sp, &file_spec, 0, FileSystem::Instance().GetByteSize(file_spec),
+  dwp_file_data_sp, dwp_file_data_offset);
+  // The presence of a debug_cu_index section is the key identifying feature of
+  // a DWP file. Make sure we don't fill in the section list on dwp_obj_file
+  // (by calling GetSectionList(false)) as this is invoked before we may have
+  // all the symbol files collected and available.
+  return dwp_obj_file && ObjectFileELF::classof(dwp_obj_file.get()) &&
+ dwp_obj_file->GetSectionList(false)->FindSectionByType(
+ eSectionTypeDWARFDebugCuIndex, false);
+}
+
 // CreateInstance
 //
 // Platforms can register a callback to use when creating symbol vendors to
diff --git a/lldb/test/API/debuginfod/Normal/TestDebuginfod.py 
b/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
new file mode 100644
index 0..a662fb9fc6e68
--- /dev/null
+++ b/lldb/test/API/debuginfod/Normal/TestDebuginfod.py
@@ -0,0 +1,187 @@
+import os
+import shutil
+import tempfile
+import struct
+
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+
+
+def getUUID(aoutuuid):
+"""
+Pull the 20 byte UUID out of the .note.gnu.build-id section that was dumped
+to a file already, as part of the build.
+"""
+with open(aoutuuid, "rb") as f:
+data = f.read(36)
+if len(data) != 36:
+return None
+header = struct.unpack_from("<4I", data)
+if len(header) != 4:
+return None
+# 4 element 'prefix', 20 bytes of uuid, 3 byte long string: 'GNU':
+if header[0] != 4 or header[1] != 20 or header[2] != 3 or header[3] != 
0x554E47:
+return None
+return data[16:].hex()
+
+
+"""
+Test support for the DebugInfoD network symbol acquisition protocol.
+This one is for simple / no split-dwarf scenarios.
+
+For no-split-dwarf scenarios, there are 2 variations:
+1 - A stripped binary with it's corresponding unstripped binary:
+2 - A stripped binary with a corresponding --only-keep-debug symbols file
+"""
+
+
+@skipUnlessPlatform(["linux", "freebsd"])
+class DebugInfodTests(TestBase):
+# No need to try every flavor of debug inf.
+NO_DEBUG_INFO_TESTCASE = True
+
+def test_normal_no_symbols(self):
+"""
+Validate behavior with no symbols or symbol locator.
+('baseline negative' behavior)
+"""
+test_root = self.config_test(["a.out"])
+self.try_breakpoint(False)
+
+def test_normal_default(self):
+"""
+Validate behavior with symbols, but no symbol locator.
+('baseline positive' behavior)
+"""
+test_root = self.config_test(["a.out", "a.out.debug"])
+self.try_breakpoint(True)
+
+def test_debuginfod_symbols(self):
+"""
+Test behavior with the full binary available from Debuginfod as
+'debuginfo' from the plug-in.
+"""
+test_root = self.config_test(["a.out"], "a.out.full")
+self.

[Lldb-commits] [lldb] [lldb] Added Debuginfod tests and fixed a couple issues (PR #92572)

[Kevin Frei via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Added Debuginfod tests and fixed a couple issues (PR #92572)

[Kevin Frei via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Added Debuginfod tests and fixed a couple issues (PR #92572)

[Kevin Frei via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Added Debuginfod tests and fixed a couple issues (PR #92572)

[Kevin Frei via lldb-commits]

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

[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)

[via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Added Debuginfod tests and fixed a couple issues (PR #92572)

[Kevin Frei via lldb-commits]

kevinfrei wrote:

FYI: The previous diff exposed a bug in some ARM code that @DavidSpicket fixed 
in #91585, but (for understandable reasons) he didn't want to be left holding 
the back on restoring this diff, so I integrated some post-land feedback from 
@labath and put the diff back up for review.

https://github.com/llvm/llvm-project/pull/92572
___
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] [compiler-rt] [lldb] [llvm] [mlir] [openmp] [polly] fix(python): fix comparison to None (PR #91857)

[Mehdi Amini via lldb-commits]

joker-eph wrote:

> It's a sed s/== None/is None/g - what is there to review?

On my I'm not asking for more reviews, this is why I commented that this should 
be **pushed** in multiple commits, I don't even need to see PRs.

Another thing also mentioned above was the problem of reverts.
If there is a problem in one of the project and this needs to be reverted, then 
it'll affect the other projects.
Also imagine that this lands, then someone refactor the python code in MLIR, 
and then LLDB finds an issue and tries to revert. They have now to figure out 
why is there a merge conflicts.

More commits in the history for unrelated projects does not seem like "noise" 
to me.

When I apply automated linter (clang-tidy), I will split these into 1 commit 
per file and push these.


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

[Lldb-commits] [lldb] [lldb][Windows] Skip the TestDataFormatterLibcxxChrono test to avoid python crash (PR #92575)

[Dmitry Vasilyev via lldb-commits]

https://github.com/slydiman created 
https://github.com/llvm/llvm-project/pull/92575

The python crashed with the exit code 0xC409 (STATUS_STACK_BUFFER_OVERRUN) 
on the command `frame variable ss_neg_seconds` running on Windows x86_64. See 
this issue for details https://github.com/llvm/llvm-project/issues/92574

>From 019dcbd636a4cee19700b8d34279d45ec715b67c Mon Sep 17 00:00:00 2001
From: Dmitry Vasilyev 
Date: Fri, 17 May 2024 20:46:18 +0400
Subject: [PATCH] [lldb][Windows] Skip the TestDataFormatterLibcxxChrono test
 to avoid python crash

The python crashed with the exit code 0xC409 (STATUS_STACK_BUFFER_OVERRUN) 
on the command `frame variable ss_neg_seconds` running on Windows x86_64. See 
this issue for details https://github.com/llvm/llvm-project/issues/92574
---
 .../libcxx/chrono/TestDataFormatterLibcxxChrono.py | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
index fb35481d55514..bb7310bc1a8c1 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
@@ -12,6 +12,9 @@
 class LibcxxChronoDataFormatterTestCase(TestBase):
 @add_test_categories(["libc++"])
 @skipIf(compiler="clang", compiler_version=["<", "17.0"])
+@skipIf(
+hostoslist=["windows"], 
bugnumber="github.com/llvm/llvm-project/issues/92574"
+)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()

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

[Lldb-commits] [lldb] [lldb][Windows] Skip the TestDataFormatterLibcxxChrono test to avoid python crash (PR #92575)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dmitry Vasilyev (slydiman)


Changes

The python crashed with the exit code 0xC409 (STATUS_STACK_BUFFER_OVERRUN) 
on the command `frame variable ss_neg_seconds` running on Windows x86_64. See 
this issue for details https://github.com/llvm/llvm-project/issues/92574

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


1 Files Affected:

- (modified) 
lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
 (+3) 


``diff
diff --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
index fb35481d55514..bb7310bc1a8c1 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/chrono/TestDataFormatterLibcxxChrono.py
@@ -12,6 +12,9 @@
 class LibcxxChronoDataFormatterTestCase(TestBase):
 @add_test_categories(["libc++"])
 @skipIf(compiler="clang", compiler_version=["<", "17.0"])
+@skipIf(
+hostoslist=["windows"], 
bugnumber="github.com/llvm/llvm-project/issues/92574"
+)
 def test_with_run_command(self):
 """Test that that file and class static variables display correctly."""
 self.build()

``




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

[Lldb-commits] [lldb] d74bc82 - [lldb] Include SBLanguages in the SWIG bindings (#92470)

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-05-17T09:58:56-07:00
New Revision: d74bc823beabbb7067a4b4ae2d69a36d874f5132

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

LOG: [lldb] Include SBLanguages in the SWIG bindings (#92470)

Added: 


Modified: 
lldb/bindings/CMakeLists.txt
lldb/bindings/headers.swig
lldb/bindings/interfaces.swig
lldb/bindings/lua/CMakeLists.txt
lldb/bindings/python/CMakeLists.txt

Removed: 




diff  --git a/lldb/bindings/CMakeLists.txt b/lldb/bindings/CMakeLists.txt
index 296eae1ae77f8..bec694e43bd7b 100644
--- a/lldb/bindings/CMakeLists.txt
+++ b/lldb/bindings/CMakeLists.txt
@@ -3,6 +3,7 @@ file(GLOB_RECURSE SWIG_SOURCES *.swig)
 file(GLOB SWIG_HEADERS
   ${LLDB_SOURCE_DIR}/include/lldb/API/*.h
   ${LLDB_SOURCE_DIR}/include/lldb/*.h
+  ${LLDB_BINARY_DIR}/include/lldb/API/SBLanguages.h
 )
 file(GLOB SWIG_PRIVATE_HEADERS
   ${LLDB_SOURCE_DIR}/include/lldb/lldb-private*.h
@@ -30,6 +31,7 @@ set(SWIG_COMMON_FLAGS
   -w361,362,509
   -features autodoc
   -I${LLDB_SOURCE_DIR}/include
+  -I${LLDB_BINARY_DIR}/include
   -I${CMAKE_CURRENT_SOURCE_DIR}
   ${DARWIN_EXTRAS}
 )

diff  --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index e8d0cda288141..ffdc3c31ec883 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -36,6 +36,7 @@
 #include "lldb/API/SBHostOS.h"
 #include "lldb/API/SBInstruction.h"
 #include "lldb/API/SBInstructionList.h"
+#include "lldb/API/SBLanguages.h"
 #include "lldb/API/SBLanguageRuntime.h"
 #include "lldb/API/SBLaunchInfo.h"
 #include "lldb/API/SBLineEntry.h"

diff  --git a/lldb/bindings/interfaces.swig b/lldb/bindings/interfaces.swig
index a31a0b4af1eb6..2a29a8dd7ef0b 100644
--- a/lldb/bindings/interfaces.swig
+++ b/lldb/bindings/interfaces.swig
@@ -114,6 +114,7 @@
 %include "lldb/API/SBHostOS.h"
 %include "lldb/API/SBInstruction.h"
 %include "lldb/API/SBInstructionList.h"
+%include "lldb/API/SBLanguages.h"
 %include "lldb/API/SBLanguageRuntime.h"
 %include "lldb/API/SBLaunchInfo.h"
 %include "lldb/API/SBLineEntry.h"

diff  --git a/lldb/bindings/lua/CMakeLists.txt 
b/lldb/bindings/lua/CMakeLists.txt
index 2d128cc1864c8..4a110f7829b03 100644
--- a/lldb/bindings/lua/CMakeLists.txt
+++ b/lldb/bindings/lua/CMakeLists.txt
@@ -3,6 +3,7 @@ add_custom_command(
   DEPENDS ${SWIG_SOURCES}
   DEPENDS ${SWIG_INTERFACES}
   DEPENDS ${SWIG_HEADERS}
+  DEPENDS lldb-sbapi-dwarf-enums
   COMMAND ${SWIG_EXECUTABLE}
   ${SWIG_COMMON_FLAGS}
   -I${CMAKE_CURRENT_SOURCE_DIR}

diff  --git a/lldb/bindings/python/CMakeLists.txt 
b/lldb/bindings/python/CMakeLists.txt
index 73b1239495e22..def6941e802bb 100644
--- a/lldb/bindings/python/CMakeLists.txt
+++ b/lldb/bindings/python/CMakeLists.txt
@@ -11,6 +11,7 @@ add_custom_command(
   DEPENDS ${SWIG_SOURCES}
   DEPENDS ${SWIG_INTERFACES}
   DEPENDS ${SWIG_HEADERS}
+  DEPENDS lldb-sbapi-dwarf-enums
   COMMAND ${SWIG_EXECUTABLE}
   ${SWIG_COMMON_FLAGS}
   -I${CMAKE_CURRENT_SOURCE_DIR}



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

[Lldb-commits] [lldb] a4ad052 - [lldb-dap] Replace `assertEquals` with `assertEqual` (NFC)

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-05-17T10:12:51-07:00
New Revision: a4ad05284e97dd188c44252846486cbfb74a884c

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

LOG: [lldb-dap] Replace `assertEquals` with `assertEqual` (NFC)

Fixes new test that were added or modified after #82073. Also fixes a
formatting issue.

Added: 


Modified: 
lldb/test/API/tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py
lldb/test/API/tools/lldb-dap/variables/TestDAP_variables.py

Removed: 




diff  --git 
a/lldb/test/API/tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py 
b/lldb/test/API/tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py
index 52c0bbfb33dad..1e0e40d4a0130 100644
--- a/lldb/test/API/tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py
+++ b/lldb/test/API/tools/lldb-dap/databreakpoint/TestDAP_setDataBreakpoints.py
@@ -27,10 +27,10 @@ def test_duplicate_start_addresses(self):
 response_x = self.dap_server.request_dataBreakpointInfo(0, "&x")
 response_arr_2 = self.dap_server.request_dataBreakpointInfo(0, "arr+2")
 # Test response from dataBreakpointInfo request.
-self.assertEquals(response_x["body"]["dataId"].split("/")[1], "4")
-self.assertEquals(response_x["body"]["accessTypes"], self.accessTypes)
-self.assertEquals(response_arr_2["body"]["dataId"].split("/")[1], "4")
-self.assertEquals(response_arr_2["body"]["accessTypes"], 
self.accessTypes)
+self.assertEqual(response_x["body"]["dataId"].split("/")[1], "4")
+self.assertEqual(response_x["body"]["accessTypes"], self.accessTypes)
+self.assertEqual(response_arr_2["body"]["dataId"].split("/")[1], "4")
+self.assertEqual(response_arr_2["body"]["accessTypes"], 
self.accessTypes)
 # The first one should be overwritten by the third one as they start at
 # the same address. This is indicated by returning {verified: False} 
for
 # the first one.
@@ -40,7 +40,7 @@ def test_duplicate_start_addresses(self):
 {"dataId": response_x["body"]["dataId"], "accessType": "write"},
 ]
 set_response = 
self.dap_server.request_setDataBreakpoint(dataBreakpoints)
-self.assertEquals(
+self.assertEqual(
 set_response["body"]["breakpoints"],
 [{"verified": False}, {"verified": True}, {"verified": True}],
 )
@@ -48,14 +48,14 @@ def test_duplicate_start_addresses(self):
 self.continue_to_next_stop()
 x_val = self.dap_server.get_local_variable_value("x")
 i_val = self.dap_server.get_local_variable_value("i")
-self.assertEquals(x_val, "2")
-self.assertEquals(i_val, "1")
+self.assertEqual(x_val, "2")
+self.assertEqual(i_val, "1")
 
 self.continue_to_next_stop()
 arr_2 = self.dap_server.get_local_variable_child("arr", "[2]")
 i_val = self.dap_server.get_local_variable_value("i")
-self.assertEquals(arr_2["value"], "42")
-self.assertEquals(i_val, "2")
+self.assertEqual(arr_2["value"], "42")
+self.assertEqual(i_val, "2")
 
 @skipIfWindows
 @skipIfRemote
@@ -72,16 +72,16 @@ def test_expression(self):
 response_x = self.dap_server.request_dataBreakpointInfo(0, "&x")
 response_arr_2 = self.dap_server.request_dataBreakpointInfo(0, "arr+2")
 # Test response from dataBreakpointInfo request.
-self.assertEquals(response_x["body"]["dataId"].split("/")[1], "4")
-self.assertEquals(response_x["body"]["accessTypes"], self.accessTypes)
-self.assertEquals(response_arr_2["body"]["dataId"].split("/")[1], "4")
-self.assertEquals(response_arr_2["body"]["accessTypes"], 
self.accessTypes)
+self.assertEqual(response_x["body"]["dataId"].split("/")[1], "4")
+self.assertEqual(response_x["body"]["accessTypes"], self.accessTypes)
+self.assertEqual(response_arr_2["body"]["dataId"].split("/")[1], "4")
+self.assertEqual(response_arr_2["body"]["accessTypes"], 
self.accessTypes)
 dataBreakpoints = [
 {"dataId": response_x["body"]["dataId"], "accessType": "write"},
 {"dataId": response_arr_2["body"]["dataId"], "accessType": 
"write"},
 ]
 set_response = 
self.dap_server.request_setDataBreakpoint(dataBreakpoints)
-self.assertEquals(
+self.assertEqual(
 set_response["body"]["breakpoints"],
 [{"verified": True}, {"verified": True}],
 )
@@ -89,14 +89,14 @@ def test_expression(self):
 self.continue_to_next_stop()
 x_val = self.dap_server.get_local_variable_value("x")
 i_val = self.dap_server.get_local_variable_value("i")
-self.assertEquals(x_val, "2")
-

[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)

[via lldb-commits]

@@ -571,6 +571,15 @@ SBStructuredData SBCommandInterpreter::GetStatistics() {
   return data;
 }
 
+SBStructuredData SBCommandInterpreter::GetTranscript() {
+  LLDB_INSTRUMENT_VA(this);
+
+  SBStructuredData data;
+  if (IsValid())
+data.m_impl_up->SetObjectSP(m_opaque_ptr->GetTranscript());

royitaqi wrote:

Made a (deep) copy in the latest commit. Added test to verify that the user's 
copy isn't modified when more commands are run in the debugger.

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

[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)

[via lldb-commits]

@@ -766,6 +768,12 @@ class CommandInterpreter : public Broadcaster,
   CommandUsageMap m_command_usages;
 
   StreamString m_transcript_stream;
+
+  /// Contains a list of handled commands, output and error. Each element in
+  /// the list is a dictionary with three keys: "command" (string), "output"
+  /// (list of strings) and optionally "error" (list of strings). Each string
+  /// in "output" and "error" is a line (without EOL characters).
+  StructuredData::ArraySP m_transcript;

royitaqi wrote:

Improve the loop as discussed (I think).

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

[Lldb-commits] [lldb] Add new Python API `SBCommandInterpreter::GetTranscript()` (PR #90703)

[via lldb-commits]

@@ -135,7 +136,8 @@ CommandInterpreter::CommandInterpreter(Debugger &debugger,
   m_skip_lldbinit_files(false), m_skip_app_init_files(false),
   m_comment_char('#'), m_batch_command_mode(false),
   m_truncation_warning(eNoOmission), m_max_depth_warning(eNoOmission),
-  m_command_source_depth(0) {
+  m_command_source_depth(0),
+  m_transcript(std::make_shared()) {

royitaqi wrote:

This is out-dated now. In the latest commit, the field is now a 
`StructuredData::Array`. The initializer has been removed.

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

[Lldb-commits] [lldb] [lldb][Windows] Skip the TestDataFormatterLibcxxChrono test to avoid python crash (PR #92575)

[Michael Buch via lldb-commits]

Michael137 wrote:

I think we should just fix https://github.com/llvm/llvm-project/issues/92574 
since it seems pretty trivial to do with an ifdef

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

[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

[via lldb-commits]

@@ -731,8 +746,11 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
-  lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
-  void *m_destroy_callback_baton = nullptr;
+  std::recursive_mutex m_destroy_callback_mutex;
+  lldb::destroy_callback_token_t m_destroy_callback_next_token = 0;
+  llvm::SmallDenseMap>
+  m_destroy_callback_and_baton;

royitaqi wrote:

Updated to use `SmallVector`.

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

[Lldb-commits] [lldb] SBDebugger: Add new APIs `AddDestroyCallback` and `RemoveDestroyCallback` (PR #89868)

[via lldb-commits]

@@ -731,8 +747,11 @@ class Debugger : public 
std::enable_shared_from_this,
   lldb::TargetSP m_dummy_target_sp;
   Diagnostics::CallbackID m_diagnostics_callback_id;
 
-  lldb_private::DebuggerDestroyCallback m_destroy_callback = nullptr;
-  void *m_destroy_callback_baton = nullptr;
+  std::recursive_mutex m_destroy_callback_mutex;

royitaqi wrote:

This is out-dated. Latest commit uses `std::mutex` and improve the loop in 
`HandleDestroyCallbacks` to avoid recurssive mutex.

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

[Lldb-commits] [lldb] bdfb04a - [lldb-dap] Bump the version to 0.2.1

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-05-17T14:00:24-07:00
New Revision: bdfb04a63d73c31ee75395064762d0d6ccb45819

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

LOG: [lldb-dap] Bump the version to 0.2.1

Bump the version to 0.2.1 to test the publishing workflow and update the
extension README and URL.

Added: 


Modified: 
lldb/tools/lldb-dap/package.json

Removed: 




diff  --git a/lldb/tools/lldb-dap/package.json 
b/lldb/tools/lldb-dap/package.json
index 45fcb83cf81d8..adffc3f0a2c58 100644
--- a/lldb/tools/lldb-dap/package.json
+++ b/lldb/tools/lldb-dap/package.json
@@ -1,7 +1,7 @@
 {
   "name": "lldb-dap",
   "displayName": "LLDB DAP",
-  "version": "0.2.0",
+  "version": "0.2.1",
   "publisher": "llvm-vs-code-extensions",
   "homepage": "https://lldb.llvm.org";,
   "description": "LLDB debugging from VSCode",



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

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

[Miro Bucko via lldb-commits]

https://github.com/mbucko updated 
https://github.com/llvm/llvm-project/pull/92014

>From 939d42eba9f88d90ac72782415640bbab360645c Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Fri, 10 May 2024 12:42:03 -0700
Subject: [PATCH] Add AddressRange to SB API

Summary:
This adds new SB API calls and classes to allow a user of the SB API to
obtain an address range from SBFunction and SBBlock.

Test Plan:
llvm-lit -sv 
llvm-project/lldb/test/API/python_api/address_range/TestAddressRange.py

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:
---
 lldb/bindings/headers.swig|   2 +
 .../interface/SBAddressRangeDocstrings.i  |   3 +
 .../interface/SBAddressRangeExtensions.i  |   1 +
 .../interface/SBAddressRangeListDocstrings.i  |   3 +
 .../interface/SBAddressRangeListExtensions.i  |  25 +++
 lldb/bindings/interfaces.swig |   6 +
 lldb/include/lldb/API/LLDB.h  |   2 +
 lldb/include/lldb/API/SBAddress.h |   1 +
 lldb/include/lldb/API/SBAddressRange.h|  65 ++
 lldb/include/lldb/API/SBAddressRangeList.h|  54 +
 lldb/include/lldb/API/SBBlock.h   |   4 +
 lldb/include/lldb/API/SBDefines.h |   2 +
 lldb/include/lldb/API/SBFunction.h|   3 +
 lldb/include/lldb/API/SBStream.h  |   2 +
 lldb/include/lldb/Core/AddressRange.h |  12 ++
 lldb/include/lldb/Core/AddressRangeListImpl.h |  51 +
 lldb/include/lldb/Symbol/Block.h  |   2 +
 lldb/include/lldb/lldb-forward.h  |   3 +
 lldb/source/API/CMakeLists.txt|   2 +
 lldb/source/API/SBAddressRange.cpp| 102 ++
 lldb/source/API/SBAddressRangeList.cpp|  81 
 lldb/source/API/SBBlock.cpp   |  10 +
 lldb/source/API/SBFunction.cpp|  14 ++
 lldb/source/Core/AddressRange.cpp |  15 ++
 lldb/source/Core/AddressRangeListImpl.cpp |  50 +
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Symbol/Block.cpp  |  16 ++
 .../API/python_api/address_range/Makefile |   3 +
 .../address_range/TestAddressRange.py | 191 ++
 .../API/python_api/address_range/main.cpp |   8 +
 30 files changed, 734 insertions(+)
 create mode 100644 lldb/bindings/interface/SBAddressRangeDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeExtensions.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListExtensions.i
 create mode 100644 lldb/include/lldb/API/SBAddressRange.h
 create mode 100644 lldb/include/lldb/API/SBAddressRangeList.h
 create mode 100644 lldb/include/lldb/Core/AddressRangeListImpl.h
 create mode 100644 lldb/source/API/SBAddressRange.cpp
 create mode 100644 lldb/source/API/SBAddressRangeList.cpp
 create mode 100644 lldb/source/Core/AddressRangeListImpl.cpp
 create mode 100644 lldb/test/API/python_api/address_range/Makefile
 create mode 100644 lldb/test/API/python_api/address_range/TestAddressRange.py
 create mode 100644 lldb/test/API/python_api/address_range/main.cpp

diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index e8d0cda288141..2b53eefc8568b 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -8,6 +8,8 @@
 %{
 #include "lldb/lldb-public.h"
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/bindings/interface/SBAddressRangeDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeDocstrings.i
new file mode 100644
index 0..650195704d73e
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"API clients can get address range information."
+) lldb::SBAddressRange;
diff --git a/lldb/bindings/interface/SBAddressRangeExtensions.i 
b/lldb/bindings/interface/SBAddressRangeExtensions.i
new file mode 100644
index 0..bca359868232d
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeExtensions.i
@@ -0,0 +1 @@
+STRING_EXTENSION_OUTSIDE(SBAddressRange)
diff --git a/lldb/bindings/interface/SBAddressRangeListDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
new file mode 100644
index 0..e4b96b9ca5931
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"Represents a list of :py:class:`SBAddressRange`."
+) lldb::SBAddressRangeList;
diff --git a/lldb/bindings/interface/SBAddressRangeListExtensions.i 
b/lldb/bindings/interface/SBAddressRangeListExtensions.i
new file mode 100644
index 0..08bfa6d9aef60
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListExtensions.i
@@ -0,0 +1,25 @@
+STRING_EXTENSION_OUTSIDE(SBAddressRangeList)
+
+%extend lldb::SBAddress

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

[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 
c675a58edec6d1a876a0d0e7d261f74764855b38...939d42eba9f88d90ac72782415640bbab360645c
 lldb/test/API/python_api/address_range/TestAddressRange.py
``





View the diff from darker here.


``diff
--- TestAddressRange.py 2024-05-17 14:39:10.00 +
+++ TestAddressRange.py 2024-05-17 21:07:58.763834 +
@@ -63,11 +63,11 @@
 loc = self.bp1.GetLocationAtIndex(0)
 loc_addr = loc.GetAddress()
 func = loc_addr.GetFunction()
 ranges = func.GetRanges()
 self.assertEqual(ranges.GetSize(), 1)
-
+
 range = ranges.GetAddressRangeAtIndex(0)
 self.assertEqual(
 range.GetByteSize(),
 func.GetEndAddress().GetOffset() - 
func.GetStartAddress().GetOffset(),
 )

``




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

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

[Miro Bucko via lldb-commits]

https://github.com/mbucko updated 
https://github.com/llvm/llvm-project/pull/92014

>From 0d8a110b922fde8e0439391f87a117c1d82913c4 Mon Sep 17 00:00:00 2001
From: Miro Bucko 
Date: Fri, 10 May 2024 12:42:03 -0700
Subject: [PATCH] Add AddressRange to SB API

Summary:
This adds new SB API calls and classes to allow a user of the SB API to
obtain an address range from SBFunction and SBBlock.

Test Plan:
llvm-lit -sv 
llvm-project/lldb/test/API/python_api/address_range/TestAddressRange.py

Reviewers: clayborg

Subscribers: lldb-commits

Tasks:

Tags:
---
 lldb/bindings/headers.swig|   2 +
 .../interface/SBAddressRangeDocstrings.i  |   3 +
 .../interface/SBAddressRangeExtensions.i  |   1 +
 .../interface/SBAddressRangeListDocstrings.i  |   3 +
 .../interface/SBAddressRangeListExtensions.i  |  25 ++
 lldb/bindings/interfaces.swig |   6 +
 lldb/include/lldb/API/LLDB.h  |   2 +
 lldb/include/lldb/API/SBAddress.h |   1 +
 lldb/include/lldb/API/SBAddressRange.h|  65 ++
 lldb/include/lldb/API/SBAddressRangeList.h|  54 +
 lldb/include/lldb/API/SBBlock.h   |   4 +
 lldb/include/lldb/API/SBDefines.h |   2 +
 lldb/include/lldb/API/SBFunction.h|   3 +
 lldb/include/lldb/API/SBStream.h  |   2 +
 lldb/include/lldb/API/SBTarget.h  |   1 +
 lldb/include/lldb/Core/AddressRange.h |  14 ++
 lldb/include/lldb/Core/AddressRangeListImpl.h |  51 +
 lldb/include/lldb/Symbol/Block.h  |   2 +
 lldb/include/lldb/lldb-forward.h  |   3 +
 lldb/source/API/CMakeLists.txt|   2 +
 lldb/source/API/SBAddressRange.cpp| 102 +
 lldb/source/API/SBAddressRangeList.cpp|  90 
 lldb/source/API/SBBlock.cpp   |  10 +
 lldb/source/API/SBFunction.cpp|  14 ++
 lldb/source/Core/AddressRange.cpp |  39 
 lldb/source/Core/AddressRangeListImpl.cpp |  50 
 lldb/source/Core/CMakeLists.txt   |   1 +
 lldb/source/Symbol/Block.cpp  |  16 ++
 .../API/python_api/address_range/Makefile |   3 +
 .../address_range/TestAddressRange.py | 215 ++
 .../API/python_api/address_range/main.cpp |   8 +
 31 files changed, 794 insertions(+)
 create mode 100644 lldb/bindings/interface/SBAddressRangeDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeExtensions.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListDocstrings.i
 create mode 100644 lldb/bindings/interface/SBAddressRangeListExtensions.i
 create mode 100644 lldb/include/lldb/API/SBAddressRange.h
 create mode 100644 lldb/include/lldb/API/SBAddressRangeList.h
 create mode 100644 lldb/include/lldb/Core/AddressRangeListImpl.h
 create mode 100644 lldb/source/API/SBAddressRange.cpp
 create mode 100644 lldb/source/API/SBAddressRangeList.cpp
 create mode 100644 lldb/source/Core/AddressRangeListImpl.cpp
 create mode 100644 lldb/test/API/python_api/address_range/Makefile
 create mode 100644 lldb/test/API/python_api/address_range/TestAddressRange.py
 create mode 100644 lldb/test/API/python_api/address_range/main.cpp

diff --git a/lldb/bindings/headers.swig b/lldb/bindings/headers.swig
index e8d0cda288141..2b53eefc8568b 100644
--- a/lldb/bindings/headers.swig
+++ b/lldb/bindings/headers.swig
@@ -8,6 +8,8 @@
 %{
 #include "lldb/lldb-public.h"
 #include "lldb/API/SBAddress.h"
+#include "lldb/API/SBAddressRange.h"
+#include "lldb/API/SBAddressRangeList.h"
 #include "lldb/API/SBAttachInfo.h"
 #include "lldb/API/SBBlock.h"
 #include "lldb/API/SBBreakpoint.h"
diff --git a/lldb/bindings/interface/SBAddressRangeDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeDocstrings.i
new file mode 100644
index 0..650195704d73e
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"API clients can get address range information."
+) lldb::SBAddressRange;
diff --git a/lldb/bindings/interface/SBAddressRangeExtensions.i 
b/lldb/bindings/interface/SBAddressRangeExtensions.i
new file mode 100644
index 0..bca359868232d
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeExtensions.i
@@ -0,0 +1 @@
+STRING_EXTENSION_OUTSIDE(SBAddressRange)
diff --git a/lldb/bindings/interface/SBAddressRangeListDocstrings.i 
b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
new file mode 100644
index 0..e4b96b9ca5931
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListDocstrings.i
@@ -0,0 +1,3 @@
+%feature("docstring",
+"Represents a list of :py:class:`SBAddressRange`."
+) lldb::SBAddressRangeList;
diff --git a/lldb/bindings/interface/SBAddressRangeListExtensions.i 
b/lldb/bindings/interface/SBAddressRangeListExtensions.i
new file mode 100644
index 0..08bfa6d9aef60
--- /dev/null
+++ b/lldb/bindings/interface/SBAddressRangeListExtensions.i
@@ -0,0 +1,25 @@
+STRING_EXTENSION_

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

[Miro Bucko via lldb-commits]

@@ -0,0 +1,102 @@
+//===-- SBAddressRange.cpp 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "lldb/API/SBAddressRange.h"
+#include "Utils.h"
+#include "lldb/API/SBAddress.h"
+#include "lldb/API/SBStream.h"
+#include "lldb/API/SBTarget.h"
+#include "lldb/Core/AddressRange.h"
+#include "lldb/Core/Section.h"
+#include "lldb/Utility/Instrumentation.h"
+#include "lldb/Utility/Stream.h"
+#include 
+#include 
+
+using namespace lldb;
+using namespace lldb_private;
+
+SBAddressRange::SBAddressRange()
+: m_opaque_up(std::make_unique()) {
+  LLDB_INSTRUMENT_VA(this);
+}
+
+SBAddressRange::SBAddressRange(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  m_opaque_up = clone(rhs.m_opaque_up);
+}
+
+SBAddressRange::SBAddressRange(lldb::SBAddress addr, lldb::addr_t byte_size)
+: m_opaque_up(std::make_unique(addr.ref(), byte_size)) {
+  LLDB_INSTRUMENT_VA(this, addr, byte_size);
+}
+
+SBAddressRange::~SBAddressRange() = default;
+
+const SBAddressRange &SBAddressRange::operator=(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (this != &rhs)
+m_opaque_up = clone(rhs.m_opaque_up);
+  return *this;
+}
+
+bool SBAddressRange::operator==(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  if (!IsValid() || !rhs.IsValid())
+return false;
+  return m_opaque_up->operator==(*(rhs.m_opaque_up));
+}
+
+bool SBAddressRange::operator!=(const SBAddressRange &rhs) {
+  LLDB_INSTRUMENT_VA(this, rhs);
+
+  return !(*this == rhs);
+}
+
+void SBAddressRange::Clear() {
+  LLDB_INSTRUMENT_VA(this);
+
+  m_opaque_up.reset();
+}
+
+bool SBAddressRange::IsValid() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  return m_opaque_up && m_opaque_up->IsValid();
+}
+
+lldb::SBAddress SBAddressRange::GetBaseAddress() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  if (!IsValid())
+return lldb::SBAddress();
+  return lldb::SBAddress(m_opaque_up->GetBaseAddress());
+}
+
+lldb::addr_t SBAddressRange::GetByteSize() const {
+  LLDB_INSTRUMENT_VA(this);
+
+  if (!IsValid())
+return 0;
+  return m_opaque_up->GetByteSize();
+}
+
+bool SBAddressRange::GetDescription(SBStream &description) {
+  LLDB_INSTRUMENT_VA(this, description);
+
+  Stream &stream = description.ref();
+  if (!IsValid()) {
+stream << "";
+return true;
+  }
+  m_opaque_up->GetDescription(&stream, nullptr);

mbucko wrote:

Need to figure out how to get hold of the current target to pass into 
GetDescription() so that we can resolve the loaded address.

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

[Lldb-commits] [lldb] Add AddressRange to SB API (PR #92014)

[Miro Bucko via lldb-commits]

@@ -0,0 +1,215 @@
+"""
+Test SBAddressRange APIs.
+"""
+
+import lldb
+from lldbsuite.test.lldbtest import *
+
+
+class AddressRangeTestCase(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+TestBase.setUp(self)
+
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+self.dbg.SetAsync(True)
+
+self.target = self.dbg.CreateTarget(exe)
+self.assertTrue(self.target, VALID_TARGET)
+self.launch_info = self.target.GetLaunchInfo()
+
self.launch_info.SetWorkingDirectory(self.get_process_working_directory())
+
+self.bp1 = self.target.BreakpointCreateByName("main", "a.out")
+self.bp2 = self.target.BreakpointCreateByName("foo", "a.out")
+self.bp3 = self.target.BreakpointCreateByName("bar", "a.out")
+
+self.assertTrue(self.bp1.IsValid())
+self.assertTrue(self.bp2.IsValid())
+self.assertTrue(self.bp3.IsValid())
+
+self.addr1 = self.bp1.GetLocationAtIndex(0).GetAddress()
+self.addr2 = self.bp2.GetLocationAtIndex(0).GetAddress()
+self.addr3 = self.bp3.GetLocationAtIndex(0).GetAddress()
+
+self.assertTrue(self.addr1.IsValid())
+self.assertTrue(self.addr2.IsValid())
+self.assertTrue(self.addr3.IsValid())
+
+def test_address_range_default(self):
+"""Testing default constructor."""
+empty_range = lldb.SBAddressRange()
+self.assertEqual(empty_range.IsValid(), False)
+
+def test_address_range_construction(self):
+"""Make sure the construction and getters work."""
+range = lldb.SBAddressRange(self.addr1, 8)
+self.assertEqual(range.IsValid(), True)
+self.assertEqual(range.GetBaseAddress(), self.addr1)
+self.assertEqual(range.GetByteSize(), 8)
+
+def test_address_range_clear(self):
+"""Make sure the clear method works."""
+range = lldb.SBAddressRange(self.addr1, 8)
+self.assertEqual(range.IsValid(), True)
+self.assertEqual(range.GetBaseAddress(), self.addr1)
+self.assertEqual(range.GetByteSize(), 8)
+
+range.Clear()
+self.assertEqual(range.IsValid(), False)
+
+def test_function(self):
+"""Make sure the range works in SBFunction APIs."""
+
+# Setup breakpoints in main
+loc = self.bp1.GetLocationAtIndex(0)
+loc_addr = loc.GetAddress()
+func = loc_addr.GetFunction()
+ranges = func.GetRanges()
+self.assertEqual(ranges.GetSize(), 1)
+
+range = ranges.GetAddressRangeAtIndex(0)
+self.assertEqual(
+range.GetByteSize(),
+func.GetEndAddress().GetOffset() - 
func.GetStartAddress().GetOffset(),
+)
+self.assertEqual(
+range.GetBaseAddress().GetOffset(),
+func.GetStartAddress().GetOffset(),
+)
+
+def test_block(self):
+"""Make sure the range works in SBBlock APIs."""
+loc = self.bp1.GetLocationAtIndex(0)
+loc_addr = loc.GetAddress()
+block = loc_addr.GetBlock()
+
+ranges = block.GetRanges()
+self.assertEqual(ranges.GetSize(), 1)
+
+range = ranges.GetAddressRangeAtIndex(0)
+self.assertEqual(
+range.GetByteSize(),
+block.GetRangeEndAddress(0).GetOffset()
+- block.GetRangeStartAddress(0).GetOffset(),
+)
+self.assertEqual(
+range.GetBaseAddress().GetOffset(),
+block.GetRangeStartAddress(0).GetOffset(),
+)
+
+def test_address_range_list(self):
+"""Make sure the SBAddressRangeList works by adding and getting 
ranges."""
+range1 = lldb.SBAddressRange(self.addr1, 8)
+range2 = lldb.SBAddressRange(self.addr2, 16)
+range3 = lldb.SBAddressRange(self.addr3, 32)
+
+range_list = lldb.SBAddressRangeList()
+self.assertEqual(range_list.GetSize(), 0)
+
+range_list.Append(range1)
+range_list.Append(range2)
+range_list.Append(range3)
+self.assertEqual(range_list.GetSize(), 3)
+self.assertRaises(IndexError, lambda: range_list[3])
+
+range1_copy = range_list.GetAddressRangeAtIndex(0)
+self.assertEqual(range1.GetByteSize(), range1_copy.GetByteSize())
+self.assertEqual(
+range1.GetBaseAddress().GetOffset(),
+range1_copy.GetBaseAddress().GetOffset(),
+)
+
+range2_copy = range_list.GetAddressRangeAtIndex(1)
+self.assertEqual(range2.GetByteSize(), range2_copy.GetByteSize())
+self.assertEqual(
+range2.GetBaseAddress().GetOffset(),
+range2_copy.GetBaseAddress().GetOffset(),
+)
+
+range3_copy = range_list.GetAddressRangeAtIndex(2)
+self.assertEqual(range3.GetByteSize(), range3_copy.GetByteSize())
+self.assertEqual(
+range3.GetBaseAddress().GetOffset(),
+range3_copy.GetBaseAddress().GetOffset(),
+)
+

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[Dave Lee via lldb-commits]

https://github.com/kastiglione created 
https://github.com/llvm/llvm-project/pull/92618

None

>From 1564ae4ce3a56fc1f11e03e82e0da1e01f25f3ed Mon Sep 17 00:00:00 2001
From: Dave Lee 
Date: Thu, 16 May 2024 14:01:22 -0700
Subject: [PATCH] [lldb] Add the word "backtrace" to bt help string

---
 lldb/source/Commands/CommandObjectThread.cpp   |  4 ++--
 lldb/source/Interpreter/CommandInterpreter.cpp | 10 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index 4397ee14ea074..db96ee2cec383 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -114,8 +114,8 @@ class CommandObjectThreadBacktrace : public 
CommandObjectIterateOverThreads {
   CommandObjectThreadBacktrace(CommandInterpreter &interpreter)
   : CommandObjectIterateOverThreads(
 interpreter, "thread backtrace",
-"Show thread call stacks.  Defaults to the current thread, thread "
-"indexes can be specified as arguments.\n"
+"Show backtraces of thread call stacks.  Defaults to the current "
+"thread, thread indexes can be specified as arguments.\n"
 "Use the thread-index \"all\" to see all threads.\n"
 "Use the thread-index \"unique\" to see threads grouped by unique "
 "call stacks.\n"
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 4c58ecc3c1848..3e470a6989bbf 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -816,11 +816,11 @@ void CommandInterpreter::LoadCommandDictionary() {
   std::unique_ptr bt_regex_cmd_up(
   new CommandObjectRegexCommand(
   *this, "_regexp-bt",
-  "Show the current thread's call stack.  Any numeric argument "
-  "displays at most that many "
-  "frames.  The argument 'all' displays all threads.  Use 'settings"
-  " set frame-format' to customize the printing of individual frames "
-  "and 'settings set thread-format' to customize the thread header.",
+  "Show backtrace of the current thread's call stack.  Any numeric "
+  "argument displays at most that many frames.  The argument 'all' "
+  "displays all threads.  Use 'settings set frame-format' to customize 
"
+  "the printing of individual frames and 'settings set thread-format' "
+  "to customize the thread header.",
   "bt [ | all]", 0, false));
   if (bt_regex_cmd_up) {
 // accept but don't document "bt -c " -- before bt was a regex

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

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[via lldb-commits]

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: Dave Lee (kastiglione)


Changes



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


2 Files Affected:

- (modified) lldb/source/Commands/CommandObjectThread.cpp (+2-2) 
- (modified) lldb/source/Interpreter/CommandInterpreter.cpp (+5-5) 


``diff
diff --git a/lldb/source/Commands/CommandObjectThread.cpp 
b/lldb/source/Commands/CommandObjectThread.cpp
index 4397ee14ea074..db96ee2cec383 100644
--- a/lldb/source/Commands/CommandObjectThread.cpp
+++ b/lldb/source/Commands/CommandObjectThread.cpp
@@ -114,8 +114,8 @@ class CommandObjectThreadBacktrace : public 
CommandObjectIterateOverThreads {
   CommandObjectThreadBacktrace(CommandInterpreter &interpreter)
   : CommandObjectIterateOverThreads(
 interpreter, "thread backtrace",
-"Show thread call stacks.  Defaults to the current thread, thread "
-"indexes can be specified as arguments.\n"
+"Show backtraces of thread call stacks.  Defaults to the current "
+"thread, thread indexes can be specified as arguments.\n"
 "Use the thread-index \"all\" to see all threads.\n"
 "Use the thread-index \"unique\" to see threads grouped by unique "
 "call stacks.\n"
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp 
b/lldb/source/Interpreter/CommandInterpreter.cpp
index 4c58ecc3c1848..3e470a6989bbf 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -816,11 +816,11 @@ void CommandInterpreter::LoadCommandDictionary() {
   std::unique_ptr bt_regex_cmd_up(
   new CommandObjectRegexCommand(
   *this, "_regexp-bt",
-  "Show the current thread's call stack.  Any numeric argument "
-  "displays at most that many "
-  "frames.  The argument 'all' displays all threads.  Use 'settings"
-  " set frame-format' to customize the printing of individual frames "
-  "and 'settings set thread-format' to customize the thread header.",
+  "Show backtrace of the current thread's call stack.  Any numeric "
+  "argument displays at most that many frames.  The argument 'all' "
+  "displays all threads.  Use 'settings set frame-format' to customize 
"
+  "the printing of individual frames and 'settings set thread-format' "
+  "to customize the thread header.",
   "bt [ | all]", 0, false));
   if (bt_regex_cmd_up) {
 // accept but don't document "bt -c " -- before bt was a regex

``




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

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[Dave Lee via lldb-commits]

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

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[Dave Lee via lldb-commits]

kastiglione wrote:

Open to alternative rewordings that include "backtrace".

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

[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)

[Adrian Prantl via lldb-commits]

adrian-prantl wrote:

> No, on the terminal it works that way by design. Unless you switch to 
> something that takes full control of your screen (like curses) there's no 
> good way to display multiple progress events at the same time and not doing 
> the shadowing (i.e. letting more recent progress events through) defeats the 
> purpose of highlighting long running operations.

@JDevlieghere I know we discussed this in the past and it made sense to me, but 
I'm right now failing to connect the dots. Why couldn't the same single-line 
interface be used to print nested events something like this?

```
Evaluating expression > Type Checking > Importing "vector" > Finding 
"begin" in Foo.o
```

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

[Lldb-commits] [lldb] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #92565)

[Adrian Prantl via lldb-commits]

@@ -2067,7 +2067,7 @@ void Debugger::HandleProgressEvent(const lldb::EventSP 
&event_sp) {
   const uint32_t term_width = GetTerminalWidth();
   const uint32_t ellipsis = 3;
   if (message.size() + ellipsis >= term_width)
-message = message.substr(0, term_width - ellipsis);
+message.resize(message.size() - ellipsis);

adrian-prantl wrote:

Can you explain why `term_width` does not appear in the new patch?

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

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[Adrian Prantl via lldb-commits]

https://github.com/adrian-prantl approved this pull request.


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

[Lldb-commits] [lldb] [WIP] [lldb][Progress] Report progress when completing types from DWARF (PR #91452)

[Jonas Devlieghere via lldb-commits]

JDevlieghere wrote:

> @JDevlieghere I know we discussed this in the past and it made sense to me, 
> but I'm right now failing to connect the dots. Why couldn't the same 
> single-line interface be used to print nested events something like this?
> 
> ```
> Evaluating expression > Type Checking > Importing "vector" > Finding 
> "begin" in Foo.o
> ```

Shadowing happens with _unrelated_ events. The problem is that you don't want 
to show something like this:

```
Evaluating expression > Type Checking > Some unrelated background operation > 
Importing "vector"
```

Or let's say you're doing some work in parallel:

```
Doing some work on thread 1 > Doing some work on thread 2 > Some nested work on 
thread 2 > Some nested work on thread 1
```

For a single event, you can update it, as we do for importing the Swift 
modules. For your example, today you can show something like this:

```
Evaluating expression: Type Checking
Evaluating expression: Importing "vector"
Evaluating expression: Finding "begin" in Foo.o 
```

Compared to your approach, you lose out on the additional context that's not 
part of the title/category before the colon. On the other hand, that's how we 
aggregate events in the progress manager.

If we want to support nested _related_ events, I think that wouldn't be too 
hard. An event could have a parent event ID and LLDB could append events that 
belong to the currently displayed event. But we'd still shadow _unrelated_ 
events. 

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

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[via lldb-commits]

jimingham wrote:

In simple aliases, apropos could get this right itself by resolving the command 
the alias points to and if THAT help string had the searched term, list the 
alias.  But bt is an alias to a regex command.  Again, you could look through 
all the branches of the regex command finding their commands and do the same.  
But you'd really want to report `bt` not `_regexp-bt`.  That's getting a bit 
involved.

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

[Lldb-commits] [lldb] [lldb] Add the word "backtrace" to bt help string (PR #92618)

[via lldb-commits]

jimingham wrote:

I'm fine with adding the to be searched for term to the alias help.

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

[Lldb-commits] [lldb] 1e9324a - [lldb] Namespace SBSourceLanguageName (NFC)

[Jonas Devlieghere via lldb-commits]

Author: Jonas Devlieghere
Date: 2024-05-17T18:43:09-07:00
New Revision: 1e9324a8c734aaa933d2672522cc22d5022c6200

URL: 
https://github.com/llvm/llvm-project/commit/1e9324a8c734aaa933d2672522cc22d5022c6200
DIFF: 
https://github.com/llvm/llvm-project/commit/1e9324a8c734aaa933d2672522cc22d5022c6200.diff

LOG: [lldb] Namespace SBSourceLanguageName (NFC)

Added: 


Modified: 
lldb/include/lldb/API/SBExpressionOptions.h
lldb/source/API/SBExpressionOptions.cpp

Removed: 




diff  --git a/lldb/include/lldb/API/SBExpressionOptions.h 
b/lldb/include/lldb/API/SBExpressionOptions.h
index 19c416d0f3bcb..a9e929a4c0bd9 100644
--- a/lldb/include/lldb/API/SBExpressionOptions.h
+++ b/lldb/include/lldb/API/SBExpressionOptions.h
@@ -71,7 +71,7 @@ class LLDB_API SBExpressionOptions {
   /// Set the language using a pair of language code and version as
   /// defined by the DWARF 6 specification.
   /// WARNING: These codes may change until DWARF 6 is finalized.
-  void SetLanguage(SBSourceLanguageName name, uint32_t version);
+  void SetLanguage(lldb::SBSourceLanguageName name, uint32_t version);
 
 #ifndef SWIG
   void SetCancelCallback(lldb::ExpressionCancelCallback callback, void *baton);

diff  --git a/lldb/source/API/SBExpressionOptions.cpp 
b/lldb/source/API/SBExpressionOptions.cpp
index ce686112ff719..15ed403eaaea1 100644
--- a/lldb/source/API/SBExpressionOptions.cpp
+++ b/lldb/source/API/SBExpressionOptions.cpp
@@ -156,7 +156,7 @@ void SBExpressionOptions::SetLanguage(lldb::LanguageType 
language) {
   m_opaque_up->SetLanguage(language);
 }
 
-void SBExpressionOptions::SetLanguage(SBSourceLanguageName name,
+void SBExpressionOptions::SetLanguage(lldb::SBSourceLanguageName name,
   uint32_t version) {
   LLDB_INSTRUMENT_VA(this, name, version);
 



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

[Lldb-commits] [lldb] [lldb] Refactor string manipulation in Debugger.cpp (#91209) (PR #92565)

[via lldb-commits]

https://github.com/aabhinavg updated 
https://github.com/llvm/llvm-project/pull/92565

>From 13fefb6846b6641900843c37746b03140063a955 Mon Sep 17 00:00:00 2001
From: aabhinavg 
Date: Fri, 17 May 2024 21:17:51 +0530
Subject: [PATCH 1/2] removed unwanted file

---
 lldb/source/Core/Debugger.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 9951fbcd3e7c3..70303173925e3 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -2067,7 +2067,7 @@ void Debugger::HandleProgressEvent(const lldb::EventSP 
&event_sp) {
   const uint32_t term_width = GetTerminalWidth();
   const uint32_t ellipsis = 3;
   if (message.size() + ellipsis >= term_width)
-message = message.substr(0, term_width - ellipsis);
+message.resize(message.size() - ellipsis);
 
   const bool use_color = GetUseColor();
   llvm::StringRef ansi_prefix = GetShowProgressAnsiPrefix();

>From 3ed69bf19942a6e9470fda66efd54b25cbac176e Mon Sep 17 00:00:00 2001
From: aabhinavg 
Date: Sat, 18 May 2024 08:39:21 +0530
Subject: [PATCH 2/2] updated the patch

---
 lldb/source/Core/Debugger.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 70303173925e3..d08aa1dc476f6 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -2067,7 +2067,7 @@ void Debugger::HandleProgressEvent(const lldb::EventSP 
&event_sp) {
   const uint32_t term_width = GetTerminalWidth();
   const uint32_t ellipsis = 3;
   if (message.size() + ellipsis >= term_width)
-message.resize(message.size() - ellipsis);
+message.resize(term_width - ellipsis);
 
   const bool use_color = GetUseColor();
   llvm::StringRef ansi_prefix = GetShowProgressAnsiPrefix();

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