[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [flang] [lld] [lldb] [llvm] [mlir] [openmp] [pstl] Finally formalise our defacto line-ending policy (PR #86318)
compnerd wrote: Philosophically, I agree with this change. Enshrining the information about the line endings into the SCM tool makes sense. I think that the concern that I have is that do we have sufficient testing for supporting line-ending dependent behaviour in the compiler? Additionally, do we have sufficient documentation for others to figure out how to ensure that git does not munge the line endings if they are introducing a test which is dependent on it? In such a case, how do we ensure that they are aware that the SCM will do so without actually checking the post-commit state with a hex editor? https://github.com/llvm/llvm-project/pull/86318 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
kevinfrei wrote: > I have such a system and have dug into the DebugInfoD "space" recently and > would be more than willing (eager, even) to help! If you are on the Discord > server, we can message and find a way to collaborate (I am hawkinsw). Just joined. I can sort of use Discord (I mentor high school robotics students, and definitely can't keep up with them). Name is 'frei4all'. I'm in the Seattle area, so 8-5, PDT. If you're free Thursday, I'm happy to see if you can help me repro (and address) the issue... https://github.com/llvm/llvm-project/pull/86812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add APFloat helper functions to Scalar class. (PR #86862)
https://github.com/bulbazord requested changes to this pull request. Could you add a test for these new methods in `unittests/Utility/ScalarTest.cpp`? https://github.com/llvm/llvm-project/pull/86862 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/86888 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] b76fd1e - [lldb] Avoid deadlock by unlocking before invoking callbacks (#86888)
Author: Jonas Devlieghere
Date: 2024-03-27T16:37:00-07:00
New Revision: b76fd1eddbafaa02a533245d574048c5ad9e38fa
URL:
https://github.com/llvm/llvm-project/commit/b76fd1eddbafaa02a533245d574048c5ad9e38fa
DIFF:
https://github.com/llvm/llvm-project/commit/b76fd1eddbafaa02a533245d574048c5ad9e38fa.diff
LOG: [lldb] Avoid deadlock by unlocking before invoking callbacks (#86888)
Avoid deadlocks in the Alarm class by releasing the lock before invoking
callbacks. This deadlock manifested itself in the ProgressManager:
1. On the main thread, the ProgressManager acquires its lock in
ProgressManager::Decrement and calls Alarm::Create.
2. On the main thread, the Alarm acquires its lock in Alarm::Create.
3. On the alarm thread, the Alarm acquires its lock after waiting on the
condition variable and calls ProgressManager::Expire.
4. On the alarm thread, the ProgressManager acquires its lock in
ProgressManager::Expire.
Note how the two threads are acquiring the locks in different orders.
Deadlocks can be avoided by always acquiring locks in the same order,
but since the two mutexes here are private implementation details,
belong to different classes, that's not straightforward. Luckily, we
don't need to have the Alarm mutex locked when invoking the callbacks.
That exactly how this patch solves the issue.
Added:
Modified:
lldb/source/Host/common/Alarm.cpp
Removed:
diff --git a/lldb/source/Host/common/Alarm.cpp
b/lldb/source/Host/common/Alarm.cpp
index 245cdc7ae5c2da..afc770d20d7b1e 100644
--- a/lldb/source/Host/common/Alarm.cpp
+++ b/lldb/source/Host/common/Alarm.cpp
@@ -154,54 +154,60 @@ lldb::thread_result_t Alarm::AlarmThread() {
//
// Below we only deal with the timeout expiring and fall through for
dealing
// with the rest.
-std::unique_lock alarm_lock(m_alarm_mutex);
-if (next_alarm) {
- if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
-// The timeout for the next alarm expired.
-
-// Clear the next timeout to signal that we need to recompute the next
-// timeout.
-next_alarm.reset();
-
-// Iterate over all the callbacks. Call the ones that have expired
-// and remove them from the list.
-const TimePoint now = std::chrono::system_clock::now();
-auto it = m_entries.begin();
-while (it != m_entries.end()) {
- if (it->expiration <= now) {
-it->callback();
-it = m_entries.erase(it);
- } else {
-it++;
+llvm::SmallVector callbacks;
+{
+ std::unique_lock alarm_lock(m_alarm_mutex);
+ if (next_alarm) {
+if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
+ // The timeout for the next alarm expired.
+
+ // Clear the next timeout to signal that we need to recompute the
next
+ // timeout.
+ next_alarm.reset();
+
+ // Iterate over all the callbacks. Call the ones that have expired
+ // and remove them from the list.
+ const TimePoint now = std::chrono::system_clock::now();
+ auto it = m_entries.begin();
+ while (it != m_entries.end()) {
+if (it->expiration <= now) {
+ callbacks.emplace_back(std::move(it->callback));
+ it = m_entries.erase(it);
+} else {
+ it++;
+}
}
}
+ } else {
+m_alarm_cv.wait(alarm_lock, predicate);
}
-} else {
- m_alarm_cv.wait(alarm_lock, predicate);
-}
-// Fall through after waiting on the condition variable. At this point
-// either the predicate is true or we woke up because an alarm expired.
+ // Fall through after waiting on the condition variable. At this point
+ // either the predicate is true or we woke up because an alarm expired.
-// The alarm thread is shutting down.
-if (m_exit) {
- exit = true;
- if (m_run_callbacks_on_exit) {
-for (Entry : m_entries)
- entry.callback();
+ // The alarm thread is shutting down.
+ if (m_exit) {
+exit = true;
+if (m_run_callbacks_on_exit) {
+ for (Entry : m_entries)
+callbacks.emplace_back(std::move(entry.callback));
+}
}
- continue;
-}
-// A new alarm was added or an alarm expired. Either way we need to
-// recompute when this thread should wake up for the next alarm.
-if (m_recompute_next_alarm || !next_alarm) {
- for (Entry : m_entries) {
-if (!next_alarm || entry.expiration < *next_alarm)
- next_alarm = entry.expiration;
+ // A new alarm was added or an alarm expired. Either way we need to
+ // recompute when this thread should wake up for the next alarm.
+ if (m_recompute_next_alarm || !next_alarm) {
+for (Entry : m_entries) {
+ if
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
https://github.com/bulbazord approved this pull request. Makes sense to me. https://github.com/llvm/llvm-project/pull/86888 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
https://github.com/adrian-prantl approved this pull request. https://github.com/llvm/llvm-project/pull/86888 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
https://github.com/JDevlieghere updated
https://github.com/llvm/llvm-project/pull/86888
>From 793f6332ddf9059d999a7236770363e226ef8dd4 Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Wed, 27 Mar 2024 16:05:21 -0700
Subject: [PATCH] [lldb] Avoid deadlock by unlocking before invoking callbacks
Avoid deadlocks in the Alarm class by releasing the lock before invoking
callbacks. This deadlock manifested itself in the ProgressManager:
1. On the main thread, the ProgressManager acquires its lock in
ProgressManager::Decrement and calls Alarm::Create.
2. On the main thread, the Alarm acquires its lock in Alarm::Create.
3. On the alarm thread, the Alarm acquires its lock after waiting on
the condition variable and calls ProgressManager::Expire.
4. On the alarm thread, the ProgressManager acquires its lock in
ProgressManager::Expire.
Note how the two threads are acquiring the locks in different orders.
Deadlocks can be avoided by always acquiring locks in the same order,
but since the two mutexes here are private implementation details,
belong to different classes, that's not straightforward. Luckily, we
don't need to have the Alarm mutex locked when invoking the callbacks.
That exactly how this patch solves the issue.
---
lldb/source/Host/common/Alarm.cpp | 84 +--
1 file changed, 45 insertions(+), 39 deletions(-)
diff --git a/lldb/source/Host/common/Alarm.cpp
b/lldb/source/Host/common/Alarm.cpp
index 245cdc7ae5c2da..afc770d20d7b1e 100644
--- a/lldb/source/Host/common/Alarm.cpp
+++ b/lldb/source/Host/common/Alarm.cpp
@@ -154,54 +154,60 @@ lldb::thread_result_t Alarm::AlarmThread() {
//
// Below we only deal with the timeout expiring and fall through for
dealing
// with the rest.
-std::unique_lock alarm_lock(m_alarm_mutex);
-if (next_alarm) {
- if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
-// The timeout for the next alarm expired.
-
-// Clear the next timeout to signal that we need to recompute the next
-// timeout.
-next_alarm.reset();
-
-// Iterate over all the callbacks. Call the ones that have expired
-// and remove them from the list.
-const TimePoint now = std::chrono::system_clock::now();
-auto it = m_entries.begin();
-while (it != m_entries.end()) {
- if (it->expiration <= now) {
-it->callback();
-it = m_entries.erase(it);
- } else {
-it++;
+llvm::SmallVector callbacks;
+{
+ std::unique_lock alarm_lock(m_alarm_mutex);
+ if (next_alarm) {
+if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
+ // The timeout for the next alarm expired.
+
+ // Clear the next timeout to signal that we need to recompute the
next
+ // timeout.
+ next_alarm.reset();
+
+ // Iterate over all the callbacks. Call the ones that have expired
+ // and remove them from the list.
+ const TimePoint now = std::chrono::system_clock::now();
+ auto it = m_entries.begin();
+ while (it != m_entries.end()) {
+if (it->expiration <= now) {
+ callbacks.emplace_back(std::move(it->callback));
+ it = m_entries.erase(it);
+} else {
+ it++;
+}
}
}
+ } else {
+m_alarm_cv.wait(alarm_lock, predicate);
}
-} else {
- m_alarm_cv.wait(alarm_lock, predicate);
-}
-// Fall through after waiting on the condition variable. At this point
-// either the predicate is true or we woke up because an alarm expired.
+ // Fall through after waiting on the condition variable. At this point
+ // either the predicate is true or we woke up because an alarm expired.
-// The alarm thread is shutting down.
-if (m_exit) {
- exit = true;
- if (m_run_callbacks_on_exit) {
-for (Entry : m_entries)
- entry.callback();
+ // The alarm thread is shutting down.
+ if (m_exit) {
+exit = true;
+if (m_run_callbacks_on_exit) {
+ for (Entry : m_entries)
+callbacks.emplace_back(std::move(entry.callback));
+}
}
- continue;
-}
-// A new alarm was added or an alarm expired. Either way we need to
-// recompute when this thread should wake up for the next alarm.
-if (m_recompute_next_alarm || !next_alarm) {
- for (Entry : m_entries) {
-if (!next_alarm || entry.expiration < *next_alarm)
- next_alarm = entry.expiration;
+ // A new alarm was added or an alarm expired. Either way we need to
+ // recompute when this thread should wake up for the next alarm.
+ if (m_recompute_next_alarm || !next_alarm) {
+for (Entry : m_entries) {
+ if (!next_alarm || entry.expiration < *next_alarm)
+next_alarm = entry.expiration;
+
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
Avoid deadlocks in the Alarm class by releasing the lock before invoking
callbacks. This deadlock manifested itself in the ProgressManager:
1. On the main thread, the ProgressManager acquires its lock in
ProgressManager::Decrement and calls Alarm::Create.
2. On the main thread, the Alarm acquires its lock in Alarm::Create.
3. On the alarm thread, the Alarm acquires its lock after waiting on the
condition variable and calls ProgressManager::Expire.
4. On the alarm thread, the ProgressManager acquires its lock in
ProgressManager::Expire.
Note how the two threads are acquiring the locks in different orders. Deadlocks
can be avoided by always acquiring locks in the same order, but since the two
mutexes here are private implementation details, belong to different classes,
that's not straightforward. Luckily, we don't need to have the Alarm mutex
locked when invoking the callbacks. That exactly how this patch solves the
issue.
---
Full diff: https://github.com/llvm/llvm-project/pull/86888.diff
1 Files Affected:
- (modified) lldb/source/Host/common/Alarm.cpp (+45-39)
``diff
diff --git a/lldb/source/Host/common/Alarm.cpp
b/lldb/source/Host/common/Alarm.cpp
index 245cdc7ae5c2da..60ac91db3ccf59 100644
--- a/lldb/source/Host/common/Alarm.cpp
+++ b/lldb/source/Host/common/Alarm.cpp
@@ -154,54 +154,60 @@ lldb::thread_result_t Alarm::AlarmThread() {
//
// Below we only deal with the timeout expiring and fall through for
dealing
// with the rest.
-std::unique_lock alarm_lock(m_alarm_mutex);
-if (next_alarm) {
- if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
-// The timeout for the next alarm expired.
-
-// Clear the next timeout to signal that we need to recompute the next
-// timeout.
-next_alarm.reset();
-
-// Iterate over all the callbacks. Call the ones that have expired
-// and remove them from the list.
-const TimePoint now = std::chrono::system_clock::now();
-auto it = m_entries.begin();
-while (it != m_entries.end()) {
- if (it->expiration <= now) {
-it->callback();
-it = m_entries.erase(it);
- } else {
-it++;
+llvm::SmallVector callbacks;
+{
+ std::unique_lock alarm_lock(m_alarm_mutex);
+ if (next_alarm) {
+if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
+ // The timeout for the next alarm expired.
+
+ // Clear the next timeout to signal that we need to recompute the
next
+ // timeout.
+ next_alarm.reset();
+
+ // Iterate over all the callbacks. Call the ones that have expired
+ // and remove them from the list.
+ const TimePoint now = std::chrono::system_clock::now();
+ auto it = m_entries.begin();
+ while (it != m_entries.end()) {
+if (it->expiration <= now) {
+ callbacks.emplace_back(std::move(it->callback));
+ it = m_entries.erase(it);
+} else {
+ it++;
+}
}
}
+ } else {
+m_alarm_cv.wait(alarm_lock, predicate);
}
-} else {
- m_alarm_cv.wait(alarm_lock, predicate);
-}
-// Fall through after waiting on the condition variable. At this point
-// either the predicate is true or we woke up because an alarm expired.
+ // Fall through after waiting on the condition variable. At this point
+ // either the predicate is true or we woke up because an alarm expired.
-// The alarm thread is shutting down.
-if (m_exit) {
- exit = true;
- if (m_run_callbacks_on_exit) {
-for (Entry : m_entries)
- entry.callback();
+ // The alarm thread is shutting down.
+ if (m_exit) {
+exit = true;
+if (m_run_callbacks_on_exit) {
+ for (Entry : m_entries)
+entry.callback();
+}
}
- continue;
-}
-// A new alarm was added or an alarm expired. Either way we need to
-// recompute when this thread should wake up for the next alarm.
-if (m_recompute_next_alarm || !next_alarm) {
- for (Entry : m_entries) {
-if (!next_alarm || entry.expiration < *next_alarm)
- next_alarm = entry.expiration;
+ // A new alarm was added or an alarm expired. Either way we need to
+ // recompute when this thread should wake up for the next alarm.
+ if (m_recompute_next_alarm || !next_alarm) {
+for (Entry : m_entries) {
+ if (!next_alarm || entry.expiration < *next_alarm)
+next_alarm = entry.expiration;
+}
+m_recompute_next_alarm = false;
}
- m_recompute_next_alarm = false;
}
+
+// Outside the lock, call the callbacks.
+for (Callback : callbacks)
+ callback();
}
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/86888
Avoid deadlocks in the Alarm class by releasing the lock before invoking
callbacks. This deadlock manifested itself in the ProgressManager:
1. On the main thread, the ProgressManager acquires its lock in
ProgressManager::Decrement and calls Alarm::Create.
2. On the main thread, the Alarm acquires its lock in Alarm::Create.
3. On the alarm thread, the Alarm acquires its lock after waiting on the
condition variable and calls ProgressManager::Expire.
4. On the alarm thread, the ProgressManager acquires its lock in
ProgressManager::Expire.
Note how the two threads are acquiring the locks in different orders. Deadlocks
can be avoided by always acquiring locks in the same order, but since the two
mutexes here are private implementation details, belong to different classes,
that's not straightforward. Luckily, we don't need to have the Alarm mutex
locked when invoking the callbacks. That exactly how this patch solves the
issue.
>From d6ae3ee129bc24bfa65fc5cf7ec9aed2333bab8c Mon Sep 17 00:00:00 2001
From: Jonas Devlieghere
Date: Wed, 27 Mar 2024 16:05:21 -0700
Subject: [PATCH] [lldb] Avoid deadlock by unlocking before invoking callbacks
Avoid deadlocks in the Alarm class by releasing the lock before invoking
callbacks. This deadlock manifested itself in the ProgressManager:
1. On the main thread, the ProgressManager acquires its lock in
ProgressManager::Decrement and calls Alarm::Create.
2. On the main thread, the Alarm acquires its lock in Alarm::Create.
3. On the alarm thread, the Alarm acquires its lock after waiting on
the condition variable and calls ProgressManager::Expire.
4. On the alarm thread, the ProgressManager acquires its lock in
ProgressManager::Expire.
Note how the two threads are acquiring the locks in different orders.
Deadlocks can be avoided by always acquiring locks in the same order,
but since the two mutexes here are private implementation details,
belong to different classes, that's not straightforward. Luckily, we
don't need to have the Alarm mutex locked when invoking the callbacks.
That exactly how this patch solves the issue.
---
lldb/source/Host/common/Alarm.cpp | 84 +--
1 file changed, 45 insertions(+), 39 deletions(-)
diff --git a/lldb/source/Host/common/Alarm.cpp
b/lldb/source/Host/common/Alarm.cpp
index 245cdc7ae5c2da..60ac91db3ccf59 100644
--- a/lldb/source/Host/common/Alarm.cpp
+++ b/lldb/source/Host/common/Alarm.cpp
@@ -154,54 +154,60 @@ lldb::thread_result_t Alarm::AlarmThread() {
//
// Below we only deal with the timeout expiring and fall through for
dealing
// with the rest.
-std::unique_lock alarm_lock(m_alarm_mutex);
-if (next_alarm) {
- if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
-// The timeout for the next alarm expired.
-
-// Clear the next timeout to signal that we need to recompute the next
-// timeout.
-next_alarm.reset();
-
-// Iterate over all the callbacks. Call the ones that have expired
-// and remove them from the list.
-const TimePoint now = std::chrono::system_clock::now();
-auto it = m_entries.begin();
-while (it != m_entries.end()) {
- if (it->expiration <= now) {
-it->callback();
-it = m_entries.erase(it);
- } else {
-it++;
+llvm::SmallVector callbacks;
+{
+ std::unique_lock alarm_lock(m_alarm_mutex);
+ if (next_alarm) {
+if (!m_alarm_cv.wait_until(alarm_lock, *next_alarm, predicate)) {
+ // The timeout for the next alarm expired.
+
+ // Clear the next timeout to signal that we need to recompute the
next
+ // timeout.
+ next_alarm.reset();
+
+ // Iterate over all the callbacks. Call the ones that have expired
+ // and remove them from the list.
+ const TimePoint now = std::chrono::system_clock::now();
+ auto it = m_entries.begin();
+ while (it != m_entries.end()) {
+if (it->expiration <= now) {
+ callbacks.emplace_back(std::move(it->callback));
+ it = m_entries.erase(it);
+} else {
+ it++;
+}
}
}
+ } else {
+m_alarm_cv.wait(alarm_lock, predicate);
}
-} else {
- m_alarm_cv.wait(alarm_lock, predicate);
-}
-// Fall through after waiting on the condition variable. At this point
-// either the predicate is true or we woke up because an alarm expired.
+ // Fall through after waiting on the condition variable. At this point
+ // either the predicate is true or we woke up because an alarm expired.
-// The alarm thread is shutting down.
-if (m_exit) {
- exit = true;
- if (m_run_callbacks_on_exit) {
-for (Entry : m_entries)
-
[Lldb-commits] [lldb] [lldb] Avoid deadlock by unlocking before invoking callbacks (PR #86888)
https://github.com/JDevlieghere ready_for_review https://github.com/llvm/llvm-project/pull/86888 ___ 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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
@@ -101,7 +101,7 @@ def extract_result_types(comment): def strip_doxygen(comment): -"""Returns the given comment without \-escaped words.""" +"""Returns the given comment without \\-escaped words.""" ellishg wrote: I see lots of changes to comment blocks in this patch. Can we use `'''` instead to fix those warnings? https://github.com/llvm/llvm-project/pull/86806 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)
jimingham wrote: > @jimingham, thanks for detailed comment. > > "Step in targets" or "Step Into Specific" is an IDE feature that works in two > steps: > > 1. Show a list of call sites before stepping to allow users specify which > call to step into > 2. Perform step into with user choosing call site function to stop. > > https://www.tabsoverspaces.com/233742-step-into-a-specific-call-when-debugging-in-visual-studio > contains a good screenshot. > > Note: in step 1, we will have to show users the callsite target function > **before** performing stepping. For indirect/virtual call, you can't reliable > resolve the target function name without running a smaller interpreter to > simulate the execution. > > > I don't think there's any way you are going to know what address > > "method_call" > > will resolve to in this context. You'd have to know what "this" actually > > is, and deal with overload resolution, etc. That does > not sound very > > doable to me. > > I am not proposing using the function target PC, but the call instruction > address in the call site side. For example: > > ``` > 0xa426 <+934>: callq 0x8990 ; bar at main.cpp:64 > 0xa42b <+939>: movl %eax, -0xb0(%rbp) > 0xa431 <+945>: callq 0x89a0 ; bar2 at main.cpp:68 > 0xa436 <+950>: movl -0xb0(%rbp), %edi > 0xa43c <+956>: movl %eax, %esi > 0xa43e <+958>: callq 0x8970 ; foo at main.cpp:60 > ``` > > For the above step range above, if user wants to step into "bar2()" function, > I propose us pass `0xa431` as an extra callsite PC to underlying > `ThreadPlanStepInRange`, so `ThreadPlanStepInRange::DoWillResume()` can > detect the current IP would match the user specified call-site PC > `0xa431`. Then > `ThreadPlanStepInRange::DefaultShouldStopHereCallback()` can detect the state > that there is a previous matching callsite PC, so return true to stop when > eFrameCompareYounger. > > Hope this makes sense. That sounds fine. I try to stay out of the game of telling people what is going to run in any given range of code because it is pretty hard to get that right from assembly, whereas if you watch execution you are always right. But if that's what the DAP requires, that seems to be your fate. It would be fine to add an `m_step_into_target_addr` to ThreadPlanStepInRange and check that in its ShouldStopHereCallback. Not sure why you mention DoWillResume, that's not where ShouldStopHere gets called, and deciding your step was done then would be way too late in the whole "I've stopped, what should I do next" negotiation. But if you put it in the ShouldStopHereCallback it will get called at the right time. https://github.com/llvm/llvm-project/pull/86623 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)
jeffreytan81 wrote: @jimingham, thanks for detailed comment. "Step in targets" or "Step Into Specific" is an IDE feature that works in two steps: 1. Show a list of call sites before stepping to allow users specify which call to step into 2. Perform step into with user choosing call site function to stop. https://www.tabsoverspaces.com/233742-step-into-a-specific-call-when-debugging-in-visual-studio contains a good screenshot. Note: in step 1, we will have to show users the callsite target function *before* performing stepping. For indirect/virtual call, you can't reliable resolve the target function name without running a smaller interpreter to simulate the execution. > I don't think there's any way you are going to know what address > "method_call" > will resolve to in this context. You'd have to know what "this" actually is, > and deal with overload resolution, etc. That does > not sound very doable to > me. I am not proposing using the function target PC, but the call instruction address in the call site side. For example: ``` 0xa426 <+934>: callq 0x8990 ; bar at main.cpp:64 0xa42b <+939>: movl %eax, -0xb0(%rbp) 0xa431 <+945>: callq 0x89a0 ; bar2 at main.cpp:68 0xa436 <+950>: movl -0xb0(%rbp), %edi 0xa43c <+956>: movl %eax, %esi 0xa43e <+958>: callq 0x8970 ; foo at main.cpp:60 ``` For the above step range above, I propose us pass `0xa431` as an extra callsite PC to underlying `ThreadPlanStepInRange`, so `ThreadPlanStepInRange::DoWillResume()` can detect the current IP would match the user specified call-site PC `0xa431`. Then `ThreadPlanStepInRange::DefaultShouldStopHereCallback()` can detect the state that there is a previous matching callsite PC, so return true to stop when eFrameCompareYounger. https://github.com/llvm/llvm-project/pull/86623 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)
@@ -3180,14 +3180,153 @@ void request_stepIn(const llvm::json::Object )
{
llvm::json::Object response;
FillResponse(request, response);
auto arguments = request.getObject("arguments");
+
+ std::string step_in_target;
+ uint64_t target_id = GetUnsigned(arguments, "targetId", 0);
+ auto it = g_dap.step_in_targets.find(target_id);
+ if (it != g_dap.step_in_targets.end())
+step_in_target = it->second;
+
+ const bool single_thread = GetBoolean(arguments, "singleThread", false);
+ lldb::RunMode run_mode =
+ single_thread ? lldb::eOnlyThisThread : lldb::eOnlyDuringStepping;
lldb::SBThread thread = g_dap.GetLLDBThread(*arguments);
if (thread.IsValid()) {
// Remember the thread ID that caused the resume so we can set the
// "threadCausedFocus" boolean value in the "stopped" events.
g_dap.focus_tid = thread.GetThreadID();
-thread.StepInto();
+thread.StepInto(step_in_target.c_str(), run_mode);
+ } else {
+response["success"] = llvm::json::Value(false);
+ }
+ g_dap.SendJSON(llvm::json::Value(std::move(response)));
+}
+
+// "StepInTargetsRequest": {
+// "allOf": [ { "$ref": "#/definitions/Request" }, {
+// "type": "object",
+// "description": "This request retrieves the possible step-in targets for
+// the specified stack frame.\nThese targets can be used in the `stepIn`
+// request.\nClients should only call this request if the corresponding
+// capability `supportsStepInTargetsRequest` is true.", "properties": {
+// "command": {
+// "type": "string",
+// "enum": [ "stepInTargets" ]
+// },
+// "arguments": {
+// "$ref": "#/definitions/StepInTargetsArguments"
+// }
+// },
+// "required": [ "command", "arguments" ]
+// }]
+// },
+// "StepInTargetsArguments": {
+// "type": "object",
+// "description": "Arguments for `stepInTargets` request.",
+// "properties": {
+// "frameId": {
+// "type": "integer",
+// "description": "The stack frame for which to retrieve the possible
+// step-in targets."
+// }
+// },
+// "required": [ "frameId" ]
+// },
+// "StepInTargetsResponse": {
+// "allOf": [ { "$ref": "#/definitions/Response" }, {
+// "type": "object",
+// "description": "Response to `stepInTargets` request.",
+// "properties": {
+// "body": {
+// "type": "object",
+// "properties": {
+// "targets": {
+// "type": "array",
+// "items": {
+// "$ref": "#/definitions/StepInTarget"
+// },
+// "description": "The possible step-in targets of the specified
+// source location."
+// }
+// },
+// "required": [ "targets" ]
+// }
+// },
+// "required": [ "body" ]
+// }]
+// }
+void request_stepInTargets(const llvm::json::Object ) {
+ llvm::json::Object response;
+ FillResponse(request, response);
+ auto arguments = request.getObject("arguments");
+
+ g_dap.step_in_targets.clear();
+ lldb::SBFrame frame = g_dap.GetLLDBFrame(*arguments);
+ if (frame.IsValid()) {
+lldb::SBAddress pc_addr = frame.GetPCAddress();
+lldb::SBAddress line_end_addr =
+pc_addr.GetLineEntry().GetSameLineContiguousAddressRangeEnd(true);
+lldb::SBInstructionList insts = g_dap.target.ReadInstructions(
+pc_addr, line_end_addr, /*flavor_string=*/nullptr);
+
+if (!insts.IsValid()) {
+ response["success"] = false;
+ response["message"] = "Failed to get instructions for frame.";
+ g_dap.SendJSON(llvm::json::Value(std::move(response)));
+ return;
+}
+
+llvm::json::Array step_in_targets;
+const auto num_insts = insts.GetSize();
+for (size_t i = 0; i < num_insts; ++i) {
+ lldb::SBInstruction inst = insts.GetInstructionAtIndex(i);
+ if (!inst.IsValid())
+break;
+
+ lldb::addr_t inst_addr = inst.GetAddress().GetLoadAddress(g_dap.target);
+
+ // Note: currently only x86/x64 supports flow kind.
+ lldb::InstructionControlFlowKind flow_kind =
+ inst.GetControlFlowKind(g_dap.target);
+ if (flow_kind == lldb::eInstructionControlFlowKindCall) {
+// Use call site instruction address as id which is easy to debug.
+llvm::json::Object step_in_target;
+step_in_target["id"] = inst_addr;
+
+llvm::StringRef call_operand_name = inst.GetOperands(g_dap.target);
+lldb::addr_t call_target_addr;
+if (call_operand_name.getAsInteger(0, call_target_addr))
+ continue;
jeffreytan81 wrote:
I have looked into using the comment. But it is not very portable:
```
0xa426 <+934>: callq 0x8990 ; bar at main.cpp:64
0xa42b <+939>: movl %eax, -0xb0(%rbp)
0xa431 <+945>: callq 0x89a0 ; bar2 at main.cpp:68
0xa436 <+950>: movl -0xb0(%rbp), %edi
0xa43c <+956>: movl %eax, %esi
[Lldb-commits] [lldb] Initial step in targets DAP support (PR #86623)
@@ -29,6 +29,9 @@ class LLDB_API SBLineEntry {
lldb::SBAddress GetEndAddress() const;
+ lldb::SBAddress
+ GetSameLineContiguousAddressRangeEnd(bool include_inlined_functions) const;
+
jeffreytan81 wrote:
@clayborg, right, I know I can do that but I did not use it for two reasons:
1. That seems to be what `GetSameLineContiguousAddressRangeEnd` API is doing
internally so I prefer to reuse the API than implement myself.
2. This seems to depend on the dwarf line table encoding which may not work for
other platforms like PDB? Hiding behind `GetSameLineContiguousAddressRangeEnd`
makes the code more resilient?
Anyway, if you still prefer us calling "GetLineEntryAtIndex" repeat, I will
change it.
https://github.com/llvm/llvm-project/pull/86623
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [ObjC runtime] Don't cast to signed when left shifting (PR #86605)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/86605 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] c7d947f - [lldb] [ObjC runtime] Don't cast to signed when left shifting (#86605)
Author: Jason Molenda Date: 2024-03-27T13:59:35-07:00 New Revision: c7d947f5e6c966bdba4db26097c3b433fcbe7841 URL: https://github.com/llvm/llvm-project/commit/c7d947f5e6c966bdba4db26097c3b433fcbe7841 DIFF: https://github.com/llvm/llvm-project/commit/c7d947f5e6c966bdba4db26097c3b433fcbe7841.diff LOG: [lldb] [ObjC runtime] Don't cast to signed when left shifting (#86605) This is fixing a report from ubsan which I don't think is super high value, but our testsuite hits it on TestDataFormatterObjCNSContainer.py so I'd like to work around it. We are getting ``` runtime error: left shift of negative value -8827055269646171913 3159 int64_t data_payload_signed = 3160 ((int64_t)((int64_t)unobfuscated -> 3161 << m_objc_debug_taggedpointer_ext_payload_lshift) >> 3162m_objc_debug_taggedpointer_ext_payload_rshift); ``` At this point `unobfuscated` is 0x858000f7 and `m_objc_debug_taggedpointer_ext_payload_lshift` is 9, so `(int64_t)0x858000f7<<9` shifts off the "sign" bit and then some zeroes etc, and that's how we get this error. We're only trying to extract some bits in the middle of the doubleword, so the fact that we're "losing" the sign is not a bug. Change the inner cast to (uint64_t). Added: Modified: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp Removed: diff --git a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp index 3e5ee6f6637303..d3fc487aed4333 100644 --- a/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp +++ b/lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.cpp @@ -3154,7 +3154,7 @@ AppleObjCRuntimeV2::TaggedPointerVendorExtended::GetClassDescriptor( << m_objc_debug_taggedpointer_ext_payload_lshift) >> m_objc_debug_taggedpointer_ext_payload_rshift); int64_t data_payload_signed = - ((int64_t)((int64_t)unobfuscated + ((int64_t)((uint64_t)unobfuscated << m_objc_debug_taggedpointer_ext_payload_lshift) >> m_objc_debug_taggedpointer_ext_payload_rshift); ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add APFloat helper functions to Scalar class. (PR #86862)
https://github.com/cmtice updated
https://github.com/llvm/llvm-project/pull/86862
>From 03ef6db02f49ab4cc4f63b32553015b4f3801b5b Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Wed, 27 Mar 2024 10:09:45 -0700
Subject: [PATCH 1/2] [LLDB] Add APFloat helper functions to Scalar class.
This adds the ability to create a Scalar from an APFloat, and to
create an APFloat from an APSInt or another APFloat.
---
lldb/include/lldb/Utility/Scalar.h | 6 +
lldb/source/Utility/Scalar.cpp | 42 ++
2 files changed, 48 insertions(+)
diff --git a/lldb/include/lldb/Utility/Scalar.h
b/lldb/include/lldb/Utility/Scalar.h
index 8e087a5ddeb855..d5e70fdf203001 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -71,6 +71,8 @@ class Scalar {
: m_type(e_int), m_integer(std::move(v), false), m_float(0.0f) {}
Scalar(llvm::APSInt v)
: m_type(e_int), m_integer(std::move(v)), m_float(0.0f) {}
+ Scalar(llvm::APFloat v)
+ : m_integer(0), m_float(v) {}
bool SignExtend(uint32_t bit_pos);
@@ -186,6 +188,10 @@ class Scalar {
Status SetValueFromData(const DataExtractor , lldb::Encoding encoding,
size_t byte_size);
+ llvm::APFloat CreateAPFloatFromAPSInt(lldb::BasicType basic_type);
+
+ llvm::APFloat CreateAPFloatFromAPFloat(lldb::BasicType basic_type);
+
protected:
Scalar::Type m_type = e_void;
llvm::APSInt m_integer;
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 5ad68065bce1b7..afcb204d8f95a5 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -813,6 +813,48 @@ bool Scalar::ExtractBitfield(uint32_t bit_size, uint32_t
bit_offset) {
return false;
}
+llvm::APFloat Scalar::CreateAPFloatFromAPSInt(lldb::BasicType basic_type) {
+ switch (basic_type) {
+case lldb::eBasicTypeFloat:
+ return llvm::APFloat(m_integer.isSigned()
+ ? llvm::APIntOps::RoundSignedAPIntToFloat(m_integer)
+ : llvm::APIntOps::RoundAPIntToFloat(m_integer));
+case lldb::eBasicTypeDouble:
+ // No way to get more precision at the moment.
+case lldb::eBasicTypeLongDouble:
+ return llvm::APFloat(m_integer.isSigned()
+ ? llvm::APIntOps::RoundSignedAPIntToDouble(
+ m_integer)
+ :
llvm::APIntOps::RoundAPIntToDouble(m_integer));
+default:
+ const llvm::fltSemantics = APFloat::IEEEsingle();
+ return llvm::APFloat::getNaN(sem);
+ }
+}
+
+llvm::APFloat Scalar::CreateAPFloatFromAPFloat(lldb::BasicType basic_type) {
+ switch (basic_type) {
+case lldb::eBasicTypeFloat: {
+ bool loses_info;
+ m_float.convert(llvm::APFloat::IEEEsingle(),
+ llvm::APFloat::rmNearestTiesToEven, _info);
+ return m_float;
+}
+case lldb::eBasicTypeDouble:
+ // No way to get more precision at the moment.
+case lldb::eBasicTypeLongDouble: {
+ bool loses_info;
+ m_float.convert(llvm::APFloat::IEEEdouble(),
+llvm::APFloat::rmNearestTiesToEven, _info);
+ return m_float;
+}
+default:
+ const llvm::fltSemantics = APFloat::IEEEsingle();
+ return llvm::APFloat::getNaN(sem);
+ }
+}
+
+
bool lldb_private::operator==(Scalar lhs, Scalar rhs) {
// If either entry is void then we can just compare the types
if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
>From 8de923d01dca34061f6a5ea7dad995ad754426ca Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Wed, 27 Mar 2024 13:17:23 -0700
Subject: [PATCH 2/2] [LLDB] Add APFloat helper functions to Scalar class.
Fix clang-format issues.
---
lldb/include/lldb/Utility/Scalar.h | 3 +-
lldb/source/Utility/Scalar.cpp | 62 +++---
2 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/lldb/include/lldb/Utility/Scalar.h
b/lldb/include/lldb/Utility/Scalar.h
index d5e70fdf203001..c89566f5e9d01a 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -71,8 +71,7 @@ class Scalar {
: m_type(e_int), m_integer(std::move(v), false), m_float(0.0f) {}
Scalar(llvm::APSInt v)
: m_type(e_int), m_integer(std::move(v)), m_float(0.0f) {}
- Scalar(llvm::APFloat v)
- : m_integer(0), m_float(v) {}
+ Scalar(llvm::APFloat v) : m_integer(0), m_float(v) {}
bool SignExtend(uint32_t bit_pos);
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index afcb204d8f95a5..e94fd459623665 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -815,46 +815,46 @@ bool Scalar::ExtractBitfield(uint32_t bit_size, uint32_t
bit_offset) {
llvm::APFloat Scalar::CreateAPFloatFromAPSInt(lldb::BasicType basic_type) {
switch (basic_type) {
-case lldb::eBasicTypeFloat:
- return llvm::APFloat(m_integer.isSigned()
-
[Lldb-commits] [lldb] [LLDB] Add APFloat helper functions to Scalar class. (PR #86862)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff dcd0f2b6103072b74b446c2d1e9ecec60001a28c
03ef6db02f49ab4cc4f63b32553015b4f3801b5b -- lldb/include/lldb/Utility/Scalar.h
lldb/source/Utility/Scalar.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/include/lldb/Utility/Scalar.h
b/lldb/include/lldb/Utility/Scalar.h
index d5e70fdf20..c89566f5e9 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -71,8 +71,7 @@ public:
: m_type(e_int), m_integer(std::move(v), false), m_float(0.0f) {}
Scalar(llvm::APSInt v)
: m_type(e_int), m_integer(std::move(v)), m_float(0.0f) {}
- Scalar(llvm::APFloat v)
- : m_integer(0), m_float(v) {}
+ Scalar(llvm::APFloat v) : m_integer(0), m_float(v) {}
bool SignExtend(uint32_t bit_pos);
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index afcb204d8f..e94fd45962 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -815,46 +815,46 @@ bool Scalar::ExtractBitfield(uint32_t bit_size, uint32_t
bit_offset) {
llvm::APFloat Scalar::CreateAPFloatFromAPSInt(lldb::BasicType basic_type) {
switch (basic_type) {
-case lldb::eBasicTypeFloat:
- return llvm::APFloat(m_integer.isSigned()
- ? llvm::APIntOps::RoundSignedAPIntToFloat(m_integer)
- : llvm::APIntOps::RoundAPIntToFloat(m_integer));
-case lldb::eBasicTypeDouble:
- // No way to get more precision at the moment.
-case lldb::eBasicTypeLongDouble:
- return llvm::APFloat(m_integer.isSigned()
- ? llvm::APIntOps::RoundSignedAPIntToDouble(
- m_integer)
- :
llvm::APIntOps::RoundAPIntToDouble(m_integer));
-default:
- const llvm::fltSemantics = APFloat::IEEEsingle();
- return llvm::APFloat::getNaN(sem);
+ case lldb::eBasicTypeFloat:
+return llvm::APFloat(
+m_integer.isSigned()
+? llvm::APIntOps::RoundSignedAPIntToFloat(m_integer)
+: llvm::APIntOps::RoundAPIntToFloat(m_integer));
+ case lldb::eBasicTypeDouble:
+// No way to get more precision at the moment.
+ case lldb::eBasicTypeLongDouble:
+return llvm::APFloat(
+m_integer.isSigned()
+? llvm::APIntOps::RoundSignedAPIntToDouble(m_integer)
+: llvm::APIntOps::RoundAPIntToDouble(m_integer));
+ default:
+const llvm::fltSemantics = APFloat::IEEEsingle();
+return llvm::APFloat::getNaN(sem);
}
}
llvm::APFloat Scalar::CreateAPFloatFromAPFloat(lldb::BasicType basic_type) {
switch (basic_type) {
-case lldb::eBasicTypeFloat: {
- bool loses_info;
- m_float.convert(llvm::APFloat::IEEEsingle(),
- llvm::APFloat::rmNearestTiesToEven, _info);
- return m_float;
-}
-case lldb::eBasicTypeDouble:
- // No way to get more precision at the moment.
-case lldb::eBasicTypeLongDouble: {
- bool loses_info;
- m_float.convert(llvm::APFloat::IEEEdouble(),
+ case lldb::eBasicTypeFloat: {
+bool loses_info;
+m_float.convert(llvm::APFloat::IEEEsingle(),
llvm::APFloat::rmNearestTiesToEven, _info);
- return m_float;
-}
-default:
- const llvm::fltSemantics = APFloat::IEEEsingle();
- return llvm::APFloat::getNaN(sem);
+return m_float;
+ }
+ case lldb::eBasicTypeDouble:
+// No way to get more precision at the moment.
+ case lldb::eBasicTypeLongDouble: {
+bool loses_info;
+m_float.convert(llvm::APFloat::IEEEdouble(),
+llvm::APFloat::rmNearestTiesToEven, _info);
+return m_float;
+ }
+ default:
+const llvm::fltSemantics = APFloat::IEEEsingle();
+return llvm::APFloat::getNaN(sem);
}
}
-
bool lldb_private::operator==(Scalar lhs, Scalar rhs) {
// If either entry is void then we can just compare the types
if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
``
https://github.com/llvm/llvm-project/pull/86862
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add APFloat helper functions to Scalar class. (PR #86862)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (cmtice)
Changes
This adds the ability to create a Scalar from an APFloat, and to create an
APFloat from an APSInt or another APFloat.
---
Full diff: https://github.com/llvm/llvm-project/pull/86862.diff
2 Files Affected:
- (modified) lldb/include/lldb/Utility/Scalar.h (+6)
- (modified) lldb/source/Utility/Scalar.cpp (+42)
``diff
diff --git a/lldb/include/lldb/Utility/Scalar.h
b/lldb/include/lldb/Utility/Scalar.h
index 8e087a5ddeb855..d5e70fdf203001 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -71,6 +71,8 @@ class Scalar {
: m_type(e_int), m_integer(std::move(v), false), m_float(0.0f) {}
Scalar(llvm::APSInt v)
: m_type(e_int), m_integer(std::move(v)), m_float(0.0f) {}
+ Scalar(llvm::APFloat v)
+ : m_integer(0), m_float(v) {}
bool SignExtend(uint32_t bit_pos);
@@ -186,6 +188,10 @@ class Scalar {
Status SetValueFromData(const DataExtractor , lldb::Encoding encoding,
size_t byte_size);
+ llvm::APFloat CreateAPFloatFromAPSInt(lldb::BasicType basic_type);
+
+ llvm::APFloat CreateAPFloatFromAPFloat(lldb::BasicType basic_type);
+
protected:
Scalar::Type m_type = e_void;
llvm::APSInt m_integer;
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 5ad68065bce1b7..afcb204d8f95a5 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -813,6 +813,48 @@ bool Scalar::ExtractBitfield(uint32_t bit_size, uint32_t
bit_offset) {
return false;
}
+llvm::APFloat Scalar::CreateAPFloatFromAPSInt(lldb::BasicType basic_type) {
+ switch (basic_type) {
+case lldb::eBasicTypeFloat:
+ return llvm::APFloat(m_integer.isSigned()
+ ? llvm::APIntOps::RoundSignedAPIntToFloat(m_integer)
+ : llvm::APIntOps::RoundAPIntToFloat(m_integer));
+case lldb::eBasicTypeDouble:
+ // No way to get more precision at the moment.
+case lldb::eBasicTypeLongDouble:
+ return llvm::APFloat(m_integer.isSigned()
+ ? llvm::APIntOps::RoundSignedAPIntToDouble(
+ m_integer)
+ :
llvm::APIntOps::RoundAPIntToDouble(m_integer));
+default:
+ const llvm::fltSemantics = APFloat::IEEEsingle();
+ return llvm::APFloat::getNaN(sem);
+ }
+}
+
+llvm::APFloat Scalar::CreateAPFloatFromAPFloat(lldb::BasicType basic_type) {
+ switch (basic_type) {
+case lldb::eBasicTypeFloat: {
+ bool loses_info;
+ m_float.convert(llvm::APFloat::IEEEsingle(),
+ llvm::APFloat::rmNearestTiesToEven, _info);
+ return m_float;
+}
+case lldb::eBasicTypeDouble:
+ // No way to get more precision at the moment.
+case lldb::eBasicTypeLongDouble: {
+ bool loses_info;
+ m_float.convert(llvm::APFloat::IEEEdouble(),
+llvm::APFloat::rmNearestTiesToEven, _info);
+ return m_float;
+}
+default:
+ const llvm::fltSemantics = APFloat::IEEEsingle();
+ return llvm::APFloat::getNaN(sem);
+ }
+}
+
+
bool lldb_private::operator==(Scalar lhs, Scalar rhs) {
// If either entry is void then we can just compare the types
if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
``
https://github.com/llvm/llvm-project/pull/86862
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add APFloat helper functions to Scalar class. (PR #86862)
https://github.com/cmtice created
https://github.com/llvm/llvm-project/pull/86862
This adds the ability to create a Scalar from an APFloat, and to create an
APFloat from an APSInt or another APFloat.
>From 03ef6db02f49ab4cc4f63b32553015b4f3801b5b Mon Sep 17 00:00:00 2001
From: Caroline Tice
Date: Wed, 27 Mar 2024 10:09:45 -0700
Subject: [PATCH] [LLDB] Add APFloat helper functions to Scalar class.
This adds the ability to create a Scalar from an APFloat, and to
create an APFloat from an APSInt or another APFloat.
---
lldb/include/lldb/Utility/Scalar.h | 6 +
lldb/source/Utility/Scalar.cpp | 42 ++
2 files changed, 48 insertions(+)
diff --git a/lldb/include/lldb/Utility/Scalar.h
b/lldb/include/lldb/Utility/Scalar.h
index 8e087a5ddeb855..d5e70fdf203001 100644
--- a/lldb/include/lldb/Utility/Scalar.h
+++ b/lldb/include/lldb/Utility/Scalar.h
@@ -71,6 +71,8 @@ class Scalar {
: m_type(e_int), m_integer(std::move(v), false), m_float(0.0f) {}
Scalar(llvm::APSInt v)
: m_type(e_int), m_integer(std::move(v)), m_float(0.0f) {}
+ Scalar(llvm::APFloat v)
+ : m_integer(0), m_float(v) {}
bool SignExtend(uint32_t bit_pos);
@@ -186,6 +188,10 @@ class Scalar {
Status SetValueFromData(const DataExtractor , lldb::Encoding encoding,
size_t byte_size);
+ llvm::APFloat CreateAPFloatFromAPSInt(lldb::BasicType basic_type);
+
+ llvm::APFloat CreateAPFloatFromAPFloat(lldb::BasicType basic_type);
+
protected:
Scalar::Type m_type = e_void;
llvm::APSInt m_integer;
diff --git a/lldb/source/Utility/Scalar.cpp b/lldb/source/Utility/Scalar.cpp
index 5ad68065bce1b7..afcb204d8f95a5 100644
--- a/lldb/source/Utility/Scalar.cpp
+++ b/lldb/source/Utility/Scalar.cpp
@@ -813,6 +813,48 @@ bool Scalar::ExtractBitfield(uint32_t bit_size, uint32_t
bit_offset) {
return false;
}
+llvm::APFloat Scalar::CreateAPFloatFromAPSInt(lldb::BasicType basic_type) {
+ switch (basic_type) {
+case lldb::eBasicTypeFloat:
+ return llvm::APFloat(m_integer.isSigned()
+ ? llvm::APIntOps::RoundSignedAPIntToFloat(m_integer)
+ : llvm::APIntOps::RoundAPIntToFloat(m_integer));
+case lldb::eBasicTypeDouble:
+ // No way to get more precision at the moment.
+case lldb::eBasicTypeLongDouble:
+ return llvm::APFloat(m_integer.isSigned()
+ ? llvm::APIntOps::RoundSignedAPIntToDouble(
+ m_integer)
+ :
llvm::APIntOps::RoundAPIntToDouble(m_integer));
+default:
+ const llvm::fltSemantics = APFloat::IEEEsingle();
+ return llvm::APFloat::getNaN(sem);
+ }
+}
+
+llvm::APFloat Scalar::CreateAPFloatFromAPFloat(lldb::BasicType basic_type) {
+ switch (basic_type) {
+case lldb::eBasicTypeFloat: {
+ bool loses_info;
+ m_float.convert(llvm::APFloat::IEEEsingle(),
+ llvm::APFloat::rmNearestTiesToEven, _info);
+ return m_float;
+}
+case lldb::eBasicTypeDouble:
+ // No way to get more precision at the moment.
+case lldb::eBasicTypeLongDouble: {
+ bool loses_info;
+ m_float.convert(llvm::APFloat::IEEEdouble(),
+llvm::APFloat::rmNearestTiesToEven, _info);
+ return m_float;
+}
+default:
+ const llvm::fltSemantics = APFloat::IEEEsingle();
+ return llvm::APFloat::getNaN(sem);
+ }
+}
+
+
bool lldb_private::operator==(Scalar lhs, Scalar rhs) {
// If either entry is void then we can just compare the types
if (lhs.m_type == Scalar::e_void || rhs.m_type == Scalar::e_void)
___
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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
https://github.com/kastiglione commented: lldb/package looks good, thanks. lldb/examples I trust lldb/test I or someone else will look at soon. https://github.com/llvm/llvm-project/pull/86806 ___ 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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
@@ -1517,7 +1517,7 @@ def buildLibrary(self, sources, lib_name): "DYLIB_NAME": lib_name, "CFLAGS_EXTRAS": "%s -I%s " % (stdflag, os.path.join(os.environ["LLDB_SRC"], "include")), -"LD_EXTRAS": "-shared -l%s\liblldb.lib" % lib_dir, kastiglione wrote: hopefully someone changes this to `os.path.join` in the future. https://github.com/llvm/llvm-project/pull/86806 ___ 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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
https://github.com/kastiglione edited https://github.com/llvm/llvm-project/pull/86806 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [flang] [libc] [libcxx] [lld] [lldb] [llvm] [NFC][IR] Add SetNoSanitize helpers (PR #86772)
https://github.com/vitalybuka closed https://github.com/llvm/llvm-project/pull/86772 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [clang] [compiler-rt] [flang] [libc] [libcxx] [lld] [lldb] [llvm] [NFC][IR] Add SetNoSanitize helpers (PR #86772)
https://github.com/vitalybuka edited https://github.com/llvm/llvm-project/pull/86772 ___ 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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
AngryLoki wrote:
But automatic replacement is not possible, because `"\n" != r"\n"`. But I
checked carefully that all changed places with `\n` and `\t` are regexps, and
in regexps it is semantically the same.
```
>>> '\n' in 'test \n test'
True
>>> r'\n' in 'test \n test'
False
>>> import re
>>> re.search('\n', 'test \n test')
>>> re.search(r'\n', 'test \n test')
```
https://github.com/llvm/llvm-project/pull/86806
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [ObjC runtime] Don't cast to signed when left shifting (PR #86605)
https://github.com/bulbazord approved this pull request. https://github.com/llvm/llvm-project/pull/86605 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] [ObjC runtime] Don't cast to signed when left shifting (PR #86605)
@@ -3154,7 +3154,7 @@ AppleObjCRuntimeV2::TaggedPointerVendorExtended::GetClassDescriptor( << m_objc_debug_taggedpointer_ext_payload_lshift) >> m_objc_debug_taggedpointer_ext_payload_rshift); int64_t data_payload_signed = - ((int64_t)((int64_t)unobfuscated + ((int64_t)((uint64_t)unobfuscated << m_objc_debug_taggedpointer_ext_payload_lshift) >> bulbazord wrote: Makes sense to me. I think this is fine then. https://github.com/llvm/llvm-project/pull/86605 ___ 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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
fmayer wrote: LGTM, verified the two strings are the same ``` >>> r"^(.*) \(in (.*)\) \((.*:\d*)\)$" == "^(.*) \(in (.*)\) \((.*:\d*)\)$" True >>> "^( *#([0-9]+) *)(0x[0-9a-f]+) *(?:in *.+)? *\((.*)\+(0x[0-9a-f]+)\)" == >>> r"^( *#([0-9]+) *)(0x[0-9a-f]+) *(?:in *.+)? *\((.*)\+(0x[0-9a-f]+)\)" ``` https://github.com/llvm/llvm-project/pull/86806 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 6a0ec8e - [lldb] Revive shell test after updating UnwindTable (#86770)
Author: Jason Molenda
Date: 2024-03-27T09:25:46-07:00
New Revision: 6a0ec8e25cba9d398cf525889c53835cf40247a3
URL:
https://github.com/llvm/llvm-project/commit/6a0ec8e25cba9d398cf525889c53835cf40247a3
DIFF:
https://github.com/llvm/llvm-project/commit/6a0ec8e25cba9d398cf525889c53835cf40247a3.diff
LOG: [lldb] Revive shell test after updating UnwindTable (#86770)
In
commit 2f63718f8567413a1c596bda803663eb58d6da5a
Author: Jason Molenda
Date: Tue Mar 26 09:07:15 2024 -0700
[lldb] Don't clear a Module's UnwindTable when adding a SymbolFile
(#86603)
I stopped clearing a Module's UnwindTable when we add a SymbolFile to
avoid the memory management problems with adding a symbol file
asynchronously while the UnwindTable is being accessed on another
thread. This broke the target-symbols-add-unwind.test shell test on
Linux which removes the DWARF debub_frame section from a binary, loads
it, then loads the unstripped binary with the DWARF debug_frame section
and checks that the UnwindPlans for a function include debug_frame.
I originally decided that I was willing to sacrifice the possiblity of
additional unwind sources from a symbol file because we rely on assembly
emulation so heavily, they're rarely critical. But there are targets
where we we don't have emluation and rely on things like DWARF
debug_frame a lot more, so this probably wasn't a good choice.
This patch adds a new UnwindTable::Update method which looks for any new
sources of unwind information and adds it to the UnwindTable, and calls
that after a new SymbolFile has been added to a Module.
Added:
lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test
Modified:
lldb/include/lldb/Symbol/UnwindTable.h
lldb/source/Core/Module.cpp
lldb/source/Symbol/UnwindTable.cpp
Removed:
diff --git a/lldb/include/lldb/Symbol/UnwindTable.h
b/lldb/include/lldb/Symbol/UnwindTable.h
index f0ce7047de2d1e..26826e5d1b497c 100644
--- a/lldb/include/lldb/Symbol/UnwindTable.h
+++ b/lldb/include/lldb/Symbol/UnwindTable.h
@@ -57,6 +57,10 @@ class UnwindTable {
ArchSpec GetArchitecture();
+ /// Called after a SymbolFile has been added to a Module to add any new
+ /// unwind sections that may now be available.
+ void Update();
+
private:
void Dump(Stream );
diff --git a/lldb/source/Core/Module.cpp b/lldb/source/Core/Module.cpp
index a520523a96521a..9c105b3f0e57a1 100644
--- a/lldb/source/Core/Module.cpp
+++ b/lldb/source/Core/Module.cpp
@@ -1009,6 +1009,8 @@ SymbolFile *Module::GetSymbolFile(bool can_create, Stream
*feedback_strm) {
m_symfile_up.reset(
SymbolVendor::FindPlugin(shared_from_this(), feedback_strm));
m_did_load_symfile = true;
+if (m_unwind_table)
+ m_unwind_table->Update();
}
}
}
diff --git a/lldb/source/Symbol/UnwindTable.cpp
b/lldb/source/Symbol/UnwindTable.cpp
index 3c1a5187b11054..11bedf3d6052e7 100644
--- a/lldb/source/Symbol/UnwindTable.cpp
+++ b/lldb/source/Symbol/UnwindTable.cpp
@@ -84,6 +84,51 @@ void UnwindTable::Initialize() {
}
}
+void UnwindTable::Update() {
+ if (!m_initialized)
+return Initialize();
+
+ std::lock_guard guard(m_mutex);
+
+ ObjectFile *object_file = m_module.GetObjectFile();
+ if (!object_file)
+return;
+
+ if (!m_object_file_unwind_up)
+m_object_file_unwind_up = object_file->CreateCallFrameInfo();
+
+ SectionList *sl = m_module.GetSectionList();
+ if (!sl)
+return;
+
+ SectionSP sect = sl->FindSectionByType(eSectionTypeEHFrame, true);
+ if (!m_eh_frame_up && sect) {
+m_eh_frame_up = std::make_unique(
+*object_file, sect, DWARFCallFrameInfo::EH);
+ }
+
+ sect = sl->FindSectionByType(eSectionTypeDWARFDebugFrame, true);
+ if (!m_debug_frame_up && sect) {
+m_debug_frame_up = std::make_unique(
+*object_file, sect, DWARFCallFrameInfo::DWARF);
+ }
+
+ sect = sl->FindSectionByType(eSectionTypeCompactUnwind, true);
+ if (!m_compact_unwind_up && sect) {
+m_compact_unwind_up =
+std::make_unique(*object_file, sect);
+ }
+
+ sect = sl->FindSectionByType(eSectionTypeARMexidx, true);
+ if (!m_arm_unwind_up && sect) {
+SectionSP sect_extab = sl->FindSectionByType(eSectionTypeARMextab, true);
+if (sect_extab.get()) {
+ m_arm_unwind_up =
+ std::make_unique(*object_file, sect, sect_extab);
+}
+ }
+}
+
UnwindTable::~UnwindTable() = default;
std::optional
diff --git a/lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test
b/lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test
new file mode 100644
index 00..5420213d405e86
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/target-symbols-add-unwind.test
@@ -0,0 +1,27 @@
+# TODO: When it's possible to run "image show-unwind" without a running
+# process, we can remove the unsupported line below, and hard-code an ELF
+# triple in the test.
+# UNSUPPORTED: system-windows,
[Lldb-commits] [lldb] [lldb] Revive shell test after updating UnwindTable (PR #86770)
https://github.com/jasonmolenda closed https://github.com/llvm/llvm-project/pull/86770 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Revive shell test after updating UnwindTable (PR #86770)
https://github.com/JDevlieghere approved this pull request. Nice! https://github.com/llvm/llvm-project/pull/86770 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
hawkinsw wrote: > The previous diff (and it's subsequent fix) were reverted as the tests didn't > work properly on the AArch64 & ARM LLDB buildbots. I made a couple more minor > changes to tests (from @clayborg's feedback) and disabled them for non > Linux-x86(_64) builds, as I don't have the ability do anything about an ARM64 > Linux failure. If I had to guess, I'd say the toolchain on the buildbots > isn't respecting the `-Wl,--build-id` flag. Maybe, one day, when I have a > Linux AArch64 system I'll dig in to it. > I have such a system and have dug into the DebugInfoD "space" recently and would be more than willing (eager, even) to help! If you are on the Discord server, we can message and find a way to collaborate (I am hawkinsw). https://github.com/llvm/llvm-project/pull/86812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Kevin Frei (kevinfrei) Changes The previous diff (and it's subsequent fix) were reverted as the tests didn't work properly on the AArch64 ARM LLDB buildbots. I made a couple more minor changes to tests (from @clayborg's feedback) and disabled them for non Linux-x86(_64) builds, as I don't have the ability do anything about an ARM64 Linux failure. If I had to guess, I'd say the toolchain on the buildbots isn't respecting the `-Wl,--build-id` flag. Maybe, one day, when I have a Linux AArch64 system I'll dig in to it. >From the reverted PR: I've migrated the tests in my https://github.com/llvm/llvm-project/pull/79181 from shell to API (at @JDevlieghere's suggestion) and addressed a couple issues that were exposed during testing. The tests first test the "normal" situation (no DebugInfoD involvement, just normal debug files sitting around), then the "no debug info" situation (to make sure the test is seeing failure properly), then it tests to validate that when DebugInfoD returns the symbols, things work properly. This is duplicated for DWP/split-dwarf scenarios. --- Patch is 24.80 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/86812.diff 10 Files Affected: - (modified) lldb/packages/Python/lldbsuite/test/make/Makefile.rules (+25-1) - (modified) lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (+25-13) - (modified) lldb/source/Plugins/SymbolLocator/CMakeLists.txt (+6-1) - (modified) lldb/source/Plugins/SymbolVendor/ELF/SymbolVendorELF.cpp (+27-2) - (added) lldb/test/API/debuginfod/Normal/Makefile (+19) - (added) lldb/test/API/debuginfod/Normal/TestDebuginfod.py (+179) - (added) lldb/test/API/debuginfod/Normal/main.c (+7) - (added) lldb/test/API/debuginfod/SplitDWARF/Makefile (+23) - (added) lldb/test/API/debuginfod/SplitDWARF/TestDebuginfodDWP.py (+188) - (added) lldb/test/API/debuginfod/SplitDWARF/main.c (+7) ``diff diff --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules index bfd249ccd43f2e..ee8793fa1b3029 100644 --- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules +++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules @@ -51,7 +51,7 @@ LLDB_BASE_DIR := $(THIS_FILE_DIR)/../../../../../ # # GNUWin32 uname gives "windows32" or "server version windows32" while # some versions of MSYS uname return "MSYS_NT*", but most environments -# standardize on "Windows_NT", so we'll make it consistent here. +# standardize on "Windows_NT", so we'll make it consistent here. # When running tests from Visual Studio, the environment variable isn't # inherited all the way down to the process spawned for make. #-- @@ -210,6 +210,12 @@ else ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" DSYM = $(EXE).debug endif + + ifeq "$(MAKE_DWP)" "YES" + MAKE_DWO := YES + DWP_NAME = $(EXE).dwp + DYLIB_DWP_NAME = $(DYLIB_NAME).dwp + endif endif LIMIT_DEBUG_INFO_FLAGS = @@ -357,6 +363,7 @@ ifneq "$(OS)" "Darwin" OBJCOPY ?= $(call replace_cc_with,objcopy) ARCHIVER ?= $(call replace_cc_with,ar) + DWP ?= $(call replace_cc_with,dwp) override AR = $(ARCHIVER) endif @@ -527,6 +534,10 @@ ifneq "$(CXX)" "" endif endif +ifeq "$(GEN_GNU_BUILD_ID)" "YES" + LDFLAGS += -Wl,--build-id +endif + #-- # DYLIB_ONLY variable can be used to skip the building of a.out. # See the sections below regarding dSYM file as well as the building of @@ -565,10 +576,17 @@ else endif else ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" +ifeq "$(SAVE_FULL_DEBUG_BINARY)" "YES" + cp "$(EXE)" "$(EXE).unstripped" +endif $(OBJCOPY) --only-keep-debug "$(EXE)" "$(DSYM)" $(OBJCOPY) --strip-debug --add-gnu-debuglink="$(DSYM)" "$(EXE)" "$(EXE)" endif +ifeq "$(MAKE_DWP)" "YES" + $(DWP) -o "$(DWP_NAME)" $(DWOS) endif +endif + #-- # Make the dylib @@ -610,9 +628,15 @@ endif else $(LD) $(DYLIB_OBJECTS) $(LDFLAGS) -shared -o "$(DYLIB_FILENAME)" ifeq "$(SPLIT_DEBUG_SYMBOLS)" "YES" + ifeq "$(SAVE_FULL_DEBUG_BINARY)" "YES" + cp "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME).unstripped" + endif $(OBJCOPY) --only-keep-debug "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME).debug" $(OBJCOPY) --strip-debug --add-gnu-debuglink="$(DYLIB_FILENAME).debug" "$(DYLIB_FILENAME)" "$(DYLIB_FILENAME)" endif +ifeq "$(MAKE_DWP)" "YES" + $(DWP) -o $(DYLIB_DWP_FILE) $(DYLIB_DWOS) +endif endif #-- diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
https://github.com/kevinfrei ready_for_review https://github.com/llvm/llvm-project/pull/86812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
https://github.com/kevinfrei updated
https://github.com/llvm/llvm-project/pull/86812
>From 5e3a35bb69b0bd6c3950deaba35a78c085bc5728 Mon Sep 17 00:00:00 2001
From: Kevin Frei
Date: Mon, 25 Mar 2024 08:23:47 -0700
Subject: [PATCH 1/4] 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 b5fe35d71032a8..a881218a56cef3 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 _sp,
+const FileSpec _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, _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 00..a662fb9fc6e686
--- /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.try_breakpoint(True)
+
+def test_debuginfod_executable(self):
+"""
+Test behavior with the full binary available from Debuginfod as
+'executable' from the plug-in.
+"""
+test_root = self.config_test(["a.out"], None, "a.out.full")
+self.try_breakpoint(True)
+
+def test_debuginfod_okd_symbols(self):
+"""
+Test behavior with the 'only-keep-debug' symbols available from
Debuginfod.
+"""
+test_root =
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
https://github.com/kevinfrei edited https://github.com/llvm/llvm-project/pull/86812 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] DebugInfoD issues, take 2 (PR #86812)
https://github.com/kevinfrei created
https://github.com/llvm/llvm-project/pull/86812
> The previous diff (and it's subsequent fix) were reverted as the tests didn't
> work properly on the AArch64 & ARM LLDB buildbots. I made a couple more minor
> changes to tests (from @clayborg's feedback) and disabled them for non
> Linux-x86(_64) builds, as I don't have the ability do anything about an ARM64
> Linux failure. If I had to guess, I'd say the toolchain on the buildbots
> isn't respecting the `-Wl,--build-id` flag. Maybe, one day, when I have a
> Linux AArch64 system I'll dig in to it.
Finally getting back to DebugInfoD tests:
I've migrated the tests in my https://github.com/llvm/llvm-project/pull/79181
from shell to API (at @JDevlieghere's suggestion) and addressed a couple issues
that came about during testing.
The tests first test the "normal" situation (no DebugInfoD involvement, just
normal debug files sitting around), then the "no debug info" situation (to make
sure the test is seeing failure properly), then it tests to validate that when
DebugInfoD returns the symbols, things work properly. This is duplicated for
DWP/split-dwarf scenarios.
>From ff90236364eed7fe71df2411ba694ea1603a9897 Mon Sep 17 00:00:00 2001
From: Kevin Frei
Date: Mon, 25 Mar 2024 08:23:47 -0700
Subject: [PATCH 1/4] 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 b5fe35d71032a8..a881218a56cef3 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 _sp,
+const FileSpec _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, _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 00..a662fb9fc6e686
--- /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)
+"""
+
[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
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 e82765bf07a978674c0e75c8b2e20f154ae24a4c...c7d6289573379be760ca9d691d62e0f87ba0ee8a .github/workflows/version-check.py clang-tools-extra/clang-tidy/add_new_check.py clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py clang-tools-extra/docs/clang-tidy/checks/gen-static-analyzer-docs.py clang/docs/tools/dump_ast_matchers.py clang/test/Analysis/check-analyzer-fixit.py clang/utils/ABITest/TypeGen.py compiler-rt/lib/asan/scripts/asan_symbolize.py cross-project-tests/debuginfo-tests/dexter/dex/command/ParseCommand.py cross-project-tests/lit.cfg.py libcxx/test/libcxx/transitive_includes.gen.py libcxx/utils/generate_escaped_output_table.py libcxx/utils/generate_width_estimation_table.py lld/test/MachO/tools/validate-unwind-info.py lld/utils/benchmark.py lldb/examples/python/crashlog.py lldb/examples/python/delta.py lldb/examples/python/gdbremote.py lldb/examples/python/jump.py lldb/examples/python/performance.py lldb/examples/python/symbolication.py lldb/packages/Python/lldbsuite/test/decorators.py lldb/packages/Python/lldbsuite/test/lldbpexpect.py lldb/packages/Python/lldbsuite/test/lldbtest.py lldb/packages/Python/lldbsuite/test/test_runner/process_control.py lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py lldb/test/API/commands/command/backticks/TestBackticksInAlias.py lldb/test/API/commands/expression/memory-allocation/TestMemoryAllocSettings.py lldb/test/API/commands/expression/test/TestExprs.py lldb/test/API/commands/gui/expand-threads-tree/TestGuiExpandThreadsTree.py lldb/test/API/commands/help/TestHelp.py lldb/test/API/commands/process/launch-with-shellexpand/TestLaunchWithShellExpand.py lldb/test/API/commands/register/register/TestRegistersUnavailable.py lldb/test/API/commands/settings/TestSettings.py lldb/test/API/commands/target/basic/TestTargetCommand.py lldb/test/API/commands/target/dump-separate-debug-info/dwo/TestDumpDwo.py lldb/test/API/commands/target/dump-separate-debug-info/oso/TestDumpOso.py lldb/test/API/commands/trace/TestTraceDumpInfo.py lldb/test/API/commands/trace/TestTraceEvents.py lldb/test/API/commands/trace/TestTraceStartStop.py lldb/test/API/commands/trace/TestTraceTSC.py lldb/test/API/driver/quit_speed/TestQuitWithProcess.py lldb/test/API/functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py lldb/test/API/functionalities/breakpoint/breakpoint_locations/TestBreakpointLocations.py lldb/test/API/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py lldb/test/API/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unordered/TestDataFormatterGenericUnordered.py lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/atomic/TestLibCxxAtomic.py lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/initializerlist/TestInitializerList.py lldb/test/API/functionalities/data-formatter/type_summary_list_arg/TestTypeSummaryListArg.py lldb/test/API/functionalities/memory-region/TestMemoryRegion.py lldb/test/API/functionalities/target_var/TestTargetVar.py lldb/test/API/iohandler/completion/TestIOHandlerCompletion.py lldb/test/API/lang/c/function_types/TestFunctionTypes.py lldb/test/API/lang/c/register_variables/TestRegisterVariables.py lldb/test/API/lang/c/set_values/TestSetValues.py lldb/test/API/lang/c/strings/TestCStrings.py lldb/test/API/lang/c/tls_globals/TestTlsGlobals.py lldb/test/API/lang/cpp/char1632_t/TestChar1632T.py lldb/test/API/lang/cpp/class_static/TestStaticVariables.py lldb/test/API/lang/cpp/class_types/TestClassTypes.py lldb/test/API/lang/cpp/dynamic-value/TestDynamicValue.py lldb/test/API/lang/cpp/namespace/TestNamespace.py lldb/test/API/lang/cpp/signed_types/TestSignedTypes.py lldb/test/API/lang/cpp/unsigned_types/TestUnsignedTypes.py lldb/test/API/lang/mixed/TestMixedLanguages.py lldb/test/API/lang/objc/foundation/TestObjCMethods.py lldb/test/API/lang/objc/foundation/TestObjCMethodsNSArray.py lldb/test/API/lang/objc/foundation/TestObjCMethodsNSError.py lldb/test/API/lang/objc/foundation/TestObjCMethodsString.py lldb/test/API/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py lldb/test/API/lang/objcxx/objc-builtin-types/TestObjCBuiltinTypes.py lldb/test/API/linux/aarch64/mte_core_file/TestAArch64LinuxMTEMemoryTagCoreFile.py lldb/test/API/linux/aarch64/mte_tag_access/TestAArch64LinuxMTEMemoryTagAccess.py
[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
https://github.com/ldionne approved this pull request. Libc++ parts LGTM. https://github.com/llvm/llvm-project/pull/86806 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][Dwarf] Add missing timer when parsing .debug_abbrev. (PR #86568)
https://github.com/ZequanWu closed https://github.com/llvm/llvm-project/pull/86568 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 9f84594 - [lldb][Dwarf] Add missing timer when parsing .debug_abbrev. (#86568)
Author: Zequan Wu
Date: 2024-03-27T10:33:25-04:00
New Revision: 9f84594e4ef87a50d1599814ba99fb735da76826
URL:
https://github.com/llvm/llvm-project/commit/9f84594e4ef87a50d1599814ba99fb735da76826
DIFF:
https://github.com/llvm/llvm-project/commit/9f84594e4ef87a50d1599814ba99fb735da76826.diff
LOG: [lldb][Dwarf] Add missing timer when parsing .debug_abbrev. (#86568)
The time spent on parsing `.debug_abbrev` is also part of debug info
parsing time.
Added:
Modified:
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
Removed:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 5f67658f86ea96..1164bc62682a9a 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -693,6 +693,7 @@ llvm::DWARFDebugAbbrev *SymbolFileDWARF::DebugAbbrev() {
if (debug_abbrev_data.GetByteSize() == 0)
return nullptr;
+ ElapsedTime elapsed(m_parse_time);
auto abbr =
std::make_unique(debug_abbrev_data.GetAsLLVM());
llvm::Error error = abbr->parse();
___
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] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
llvmbot wrote: @llvm/pr-subscribers-libcxx @llvm/pr-subscribers-clang-tidy @llvm/pr-subscribers-lldb @llvm/pr-subscribers-clang @llvm/pr-subscribers-mlir Author: None (AngryLoki) Changes This fixes "SyntaxWarning: invalid escape sequence" and "SyntaxWarning: "is" with 'int' literal", except for polly and summarizeStats.py, which won't run on Python 3. The fix is done in every file, because otherwise with OS-wide Python 3.12 these SyntaxWarnings appear here and there, as Python 3.12 [now produce a SyntaxWarning](https://docs.python.org/3/whatsnew/3.12.html#other-language-changes) instead of DeprecationWarning. There are no warnings anymore, which can be checked with `python -m compileall -x "polly|summarizeStats.py" -d . -f -q .` --- Patch is 128.29 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/86806.diff 106 Files Affected: - (modified) .github/workflows/version-check.py (+1-1) - (modified) clang-tools-extra/clang-tidy/add_new_check.py (+6-6) - (modified) clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py (+2-2) - (modified) clang-tools-extra/docs/clang-tidy/checks/gen-static-analyzer-docs.py (+1-1) - (modified) clang/docs/tools/dump_ast_matchers.py (+2-2) - (modified) clang/test/Analysis/check-analyzer-fixit.py (+1-1) - (modified) clang/utils/ABITest/TypeGen.py (+1-1) - (modified) compiler-rt/lib/asan/scripts/asan_symbolize.py (+2-2) - (modified) cross-project-tests/debuginfo-tests/dexter/dex/command/ParseCommand.py (+2-2) - (modified) cross-project-tests/lit.cfg.py (+3-3) - (modified) libcxx/test/libcxx/transitive_includes.gen.py (+1-1) - (modified) libcxx/utils/generate_escaped_output_table.py (+1-1) - (modified) libcxx/utils/generate_width_estimation_table.py (+1-1) - (modified) lld/test/MachO/tools/validate-unwind-info.py (+1-1) - (modified) lld/utils/benchmark.py (+1-1) - (modified) lldb/examples/python/crashlog.py (+4-4) - (modified) lldb/examples/python/delta.py (+1-1) - (modified) lldb/examples/python/gdbremote.py (+5-5) - (modified) lldb/examples/python/jump.py (+3-3) - (modified) lldb/examples/python/performance.py (+1-1) - (modified) lldb/examples/python/symbolication.py (+4-4) - (modified) lldb/packages/Python/lldbsuite/test/decorators.py (+1-1) - (modified) lldb/packages/Python/lldbsuite/test/lldbpexpect.py (+1-1) - (modified) lldb/packages/Python/lldbsuite/test/lldbtest.py (+1-1) - (modified) lldb/packages/Python/lldbsuite/test/test_runner/process_control.py (+1-1) - (modified) lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py (+2-2) - (modified) lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py (+1-1) - (modified) lldb/test/API/commands/command/backticks/TestBackticksInAlias.py (+2-2) - (modified) lldb/test/API/commands/expression/memory-allocation/TestMemoryAllocSettings.py (+1-1) - (modified) lldb/test/API/commands/expression/test/TestExprs.py (+1-1) - (modified) lldb/test/API/commands/gui/expand-threads-tree/TestGuiExpandThreadsTree.py (+1-1) - (modified) lldb/test/API/commands/help/TestHelp.py (+3-3) - (modified) lldb/test/API/commands/process/launch-with-shellexpand/TestLaunchWithShellExpand.py (+1-1) - (modified) lldb/test/API/commands/register/register/TestRegistersUnavailable.py (+2-2) - (modified) lldb/test/API/commands/settings/TestSettings.py (+6-6) - (modified) lldb/test/API/commands/target/basic/TestTargetCommand.py (+1-1) - (modified) lldb/test/API/commands/target/dump-separate-debug-info/dwo/TestDumpDwo.py (+10-10) - (modified) lldb/test/API/commands/target/dump-separate-debug-info/oso/TestDumpOso.py (+11-11) - (modified) lldb/test/API/commands/trace/TestTraceDumpInfo.py (+1-1) - (modified) lldb/test/API/commands/trace/TestTraceEvents.py (+2-2) - (modified) lldb/test/API/commands/trace/TestTraceStartStop.py (+6-6) - (modified) lldb/test/API/commands/trace/TestTraceTSC.py (+5-5) - (modified) lldb/test/API/driver/quit_speed/TestQuitWithProcess.py (+1-1) - (modified) lldb/test/API/functionalities/breakpoint/breakpoint_by_line_and_column/TestBreakpointByLineAndColumn.py (+1-1) - (modified) lldb/test/API/functionalities/breakpoint/breakpoint_locations/TestBreakpointLocations.py (+2-2) - (modified) lldb/test/API/functionalities/data-formatter/data-formatter-advanced/TestDataFormatterAdv.py (+3-3) - (modified) lldb/test/API/functionalities/data-formatter/data-formatter-cpp/TestDataFormatterCpp.py (+3-3) - (modified) lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSContainer.py (+8-8) - (modified) lldb/test/API/functionalities/data-formatter/data-formatter-skip-summary/TestDataFormatterSkipSummary.py (+1-1) - (modified) lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/unordered/TestDataFormatterGenericUnordered.py (+11-11) - (modified)
[Lldb-commits] [clang] [clang-tools-extra] [compiler-rt] [libcxx] [lld] [lldb] [llvm] [mlir] Fix SyntaxWarning messages from python 3.12 (PR #86806)
github-actions[bot] wrote: Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be notified. If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using `@` followed by their GitHub username. If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers. If you have further questions, they may be answered by the [LLVM GitHub User Guide](https://llvm.org/docs/GitHub.html). You can also ask questions in a comment on this PR, on the [LLVM Discord](https://discord.com/invite/xS7Z362) or on the [forums](https://discourse.llvm.org/). https://github.com/llvm/llvm-project/pull/86806 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 2cb7ea1 - [lldb][nfc] Delete unused variable (#86740)
Author: Felipe de Azevedo Piovezan Date: 2024-03-27T07:02:12-07:00 New Revision: 2cb7ea1553a5c7be81bee4ed3c51b7727b9d2ee8 URL: https://github.com/llvm/llvm-project/commit/2cb7ea1553a5c7be81bee4ed3c51b7727b9d2ee8 DIFF: https://github.com/llvm/llvm-project/commit/2cb7ea1553a5c7be81bee4ed3c51b7727b9d2ee8.diff LOG: [lldb][nfc] Delete unused variable (#86740) This was made unused by d9ec4b24a84addb8bd77b5d9dd990181351cf84c. Added: Modified: lldb/source/Target/StackFrame.cpp Removed: diff --git a/lldb/source/Target/StackFrame.cpp b/lldb/source/Target/StackFrame.cpp index 3af62f52d57546..03a74f29e76e99 100644 --- a/lldb/source/Target/StackFrame.cpp +++ b/lldb/source/Target/StackFrame.cpp @@ -1800,7 +1800,6 @@ void StackFrame::DumpUsingSettingsFormat(Stream *strm, bool show_unique, return; ExecutionContext exe_ctx(shared_from_this()); - StreamString s; const FormatEntity::Entry *frame_format = nullptr; Target *target = exe_ctx.GetTargetPtr(); ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][nfc] Delete unused variable (PR #86740)
https://github.com/felipepiovezan closed https://github.com/llvm/llvm-project/pull/86740 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Revive shell test after updating UnwindTable (PR #86770)
https://github.com/jasonmolenda edited https://github.com/llvm/llvm-project/pull/86770 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Revive shell test after updating UnwindTable (PR #86770)
https://github.com/jasonmolenda edited https://github.com/llvm/llvm-project/pull/86770 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
