[Lldb-commits] [lldb] [lldb-dap] Send an Invalidated event on thread stack change. (PR #163976)

2025-10-19 Thread Ebuka Ezike via lldb-commits
https://github.com/da-viper updated https://github.com/llvm/llvm-project/pull/163976 >From c20a05867dc386698c28d6244b88959686b29c48 Mon Sep 17 00:00:00 2001 From: Ebuka Ezike Date: Fri, 17 Oct 2025 11:39:20 +0100 Subject: [PATCH 1/3] [lldb-dap] Send an Invalidated event on thread stack change.

[Lldb-commits] [lldb] [lldb] Show signal number description (PR #164176)

2025-10-19 Thread via lldb-commits
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Ebuka Ezike (da-viper) Changes show information about the signal when the user presses `process handle ` i.e ```sh (lldb) process handle SIGWINCH NAME PASS STOP NOTIFY DESCRIPTION === = = ===

[Lldb-commits] [lldb] [lldb] Show signal number description (PR #164176)

2025-10-19 Thread Ebuka Ezike via lldb-commits
https://github.com/da-viper created https://github.com/llvm/llvm-project/pull/164176 show information about the signal when the user presses `process handle ` i.e ```sh (lldb) process handle SIGWINCH NAME PASS STOP NOTIFY DESCRIPTION === = = == =

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

2025-10-19 Thread Felipe de Azevedo Piovezan via lldb-commits
@@ -1571,6 +1571,25 @@ class Process : public std::enable_shared_from_this, virtual size_t ReadMemory(lldb::addr_t vm_addr, void *buf, size_t size, Status &error); + /// Read from multiple memory ranges and write the results into buffer. ---

[Lldb-commits] [lldb] [lldb] support attaching by name for platform android (PR #160931)

2025-10-19 Thread Emre Kultursay via lldb-commits
emrekultursay wrote: This PR seems to have broken the `platform process list` behavior for Android: #164192 https://github.com/llvm/llvm-project/pull/160931 ___ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mail

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

2025-10-19 Thread Felipe de Azevedo Piovezan via lldb-commits
@@ -225,3 +227,63 @@ TEST_F(MemoryTest, TesetMemoryCacheRead) { // instead of using an // old cache } + +/// A process class that reads `lower_byte(address)` for each `

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

2025-10-19 Thread Felipe de Azevedo Piovezan via lldb-commits
@@ -225,3 +227,63 @@ TEST_F(MemoryTest, TesetMemoryCacheRead) { // instead of using an // old cache } + +/// A process class that reads `lower_byte(address)` for each `

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

2025-10-19 Thread Felipe de Azevedo Piovezan via lldb-commits
@@ -1971,6 +1971,34 @@ size_t Process::ReadMemory(addr_t addr, void *buf, size_t size, Status &error) { } } +llvm::SmallVector> +Process::ReadMemoryRanges(llvm::ArrayRef> ranges, + llvm::MutableArrayRef buffer) { + llvm::SmallVector> results; + +

[Lldb-commits] [lldb] [lldb] Remove a redundant call to std::unique_ptr::get (NFC) (PR #164191)

2025-10-19 Thread Kazu Hirata via lldb-commits
https://github.com/kazutakahirata created https://github.com/llvm/llvm-project/pull/164191 None >From cf21a5bd82a0582b2a140d6f2d71615e162e93b6 Mon Sep 17 00:00:00 2001 From: Kazu Hirata Date: Sat, 18 Oct 2025 13:22:08 -0700 Subject: [PATCH] [lldb] Remove a redundant call to std::unique_ptr::ge

[Lldb-commits] [lldb] [lldb] Remove a redundant call to std::unique_ptr::get (NFC) (PR #164191)

2025-10-19 Thread via lldb-commits
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Kazu Hirata (kazutakahirata) Changes --- Full diff: https://github.com/llvm/llvm-project/pull/164191.diff 1 Files Affected: - (modified) lldb/unittests/DAP/TestBase.cpp (+1-1) ``diff diff --git a/lldb/unittests/DAP/TestBase.c

[Lldb-commits] [lldb] [lldb] Implement Process::ReadMemoryRanges (PR #163651)

2025-10-19 Thread Felipe de Azevedo Piovezan via lldb-commits
felipepiovezan wrote: > What's the thinking for doing this in "ptrace style" where the caller > allocates a buffer and gives it to the function, vs. allocating the buffer on > behalf of the caller? No real motivation other than "the other APIs in `Process` do this, so this must have been disc