https://github.com/DavidSpickett approved this pull request.
https://github.com/llvm/llvm-project/pull/82670
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Author: Adrian Prantl
Date: 2024-02-23T08:00:58-08:00
New Revision: 55bc0488af077acb47be70542718d1bc17f3de4f
URL:
https://github.com/llvm/llvm-project/commit/55bc0488af077acb47be70542718d1bc17f3de4f
DIFF:
https://github.com/llvm/llvm-project/commit/55bc0488af077acb47be70542718d1bc17f3de4f.diff
https://github.com/adrian-prantl closed
https://github.com/llvm/llvm-project/pull/82717
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/JDevlieghere created
https://github.com/llvm/llvm-project/pull/82799
When terminating the debugger, we wait for all background tasks to complete.
Given that there's no way to interrupt those treads, this can take a while.
When that happens, the debugger appears to hang at ex
https://github.com/JDevlieghere edited
https://github.com/llvm/llvm-project/pull/82799
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Jonas Devlieghere (JDevlieghere)
Changes
When terminating the debugger, we wait for all background tasks to complete.
Given that there's no way to interrupt those treads, this can take a while.
When that happens, the debugger appears to ha
https://github.com/jimingham edited
https://github.com/llvm/llvm-project/pull/82709
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -1722,6 +1742,8 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
} else {
bool handled = false;
bool did_exec = false;
+ if (reason == "none")
jimingham wrote:
This definitely needs a comment, or maybe somewhere else saying that none ==
https://github.com/jimingham approved this pull request.
This seems safe to me, and it can't hurt to take care of this corner case here
regardless of what the higher levels of lldb does.
It bugs me a little that we're treating what seems like a general problem down
in the GDBRemote process plu
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/81564
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/clayborg requested changes to this pull request.
https://github.com/llvm/llvm-project/pull/81564
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
+ pid_t child_pid = vfork();
+
+ if (child_pid == -1) {
+// Error handling
+pe
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
clayborg wrote:
We probably want to test with both `fork()` and `vfork
@@ -5681,7 +5685,10 @@ void ProcessGDBRemote::DidVForkDone() {
void ProcessGDBRemote::DidExec() {
// If we are following children, vfork is finished by exec (rather than
// vforkdone that is submitted for parent).
- if (GetFollowForkMode() == eFollowChild)
-m_vfork_in_
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
+ pid_t child_pid = vfork();
clayborg wrote:
Use either `fork()` of `
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
+ pid_t child_pid = vfork();
+
+ if (child_pid == -1) {
+// Error handling
+pe
@@ -5670,8 +5673,9 @@ void ProcessGDBRemote::DidVFork(lldb::pid_t child_pid,
lldb::tid_t child_tid) {
}
void ProcessGDBRemote::DidVForkDone() {
- assert(m_vfork_in_progress);
- m_vfork_in_progress = false;
+ assert(m_vfork_in_progress_count > 0);
+ if (m_vfork_in_progress
@@ -5615,8 +5614,12 @@ void ProcessGDBRemote::DidFork(lldb::pid_t child_pid,
lldb::tid_t child_tid) {
void ProcessGDBRemote::DidVFork(lldb::pid_t child_pid, lldb::tid_t child_tid) {
Log *log = GetLog(GDBRLog::Process);
- assert(!m_vfork_in_progress);
- m_vfork_in_progress
@@ -0,0 +1,49 @@
+"""
+Make sure that the concurrent vfork() from multiple threads works correctly.
+"""
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+
+
+class TestConcurrentVFork(Test
@@ -0,0 +1,49 @@
+"""
+Make sure that the concurrent vfork() from multiple threads works correctly.
+"""
+
+
+import lldb
+import lldbsuite.test.lldbutil as lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+
+
+class TestConcurrentVFork(Test
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
+ pid_t child_pid = vfork();
+
+ if (child_pid == -1) {
+// Error handling
+pe
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
+ pid_t child_pid = vfork();
+
+ if (child_pid == -1) {
+// Error handling
+pe
@@ -0,0 +1,70 @@
+#include
+#include
+#include
+#include
+#include
+#include
+
+pid_t g_pid = 0;
+std::mutex g_child_pids_mutex;
+std::vector g_child_pids;
+
+int call_vfork(int index) {
+ pid_t child_pid = vfork();
+
+ if (child_pid == -1) {
+// Error handling
+pe
https://github.com/adrian-prantl created
https://github.com/llvm/llvm-project/pull/82804
Looking ast the definition of both functions this is *almost* an NFC change,
except that Triple also looks at the SubArch (important) and ObjectFormat (less
so).
This fixes a bug that only manifests with
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Adrian Prantl (adrian-prantl)
Changes
Looking ast the definition of both functions this is *almost* an NFC change,
except that Triple also looks at the SubArch (important) and ObjectFormat (less
so).
This fixes a bug that only manifests w
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
750981f1a2c6069cded709b75cc87d7abd05277a...f1541edda94503adfaa52ef75e1fb53fce5f608e
lldb/
@@ -0,0 +1,2 @@
+C_SOURCES := main.c
+include Makefile.rules
JDevlieghere wrote:
Did you want to build this test for arm64**e**?
https://github.com/llvm/llvm-project/pull/82804
___
lldb-commits mailing list
lldb-commi
@@ -0,0 +1,25 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestArm64eAttach(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+# On Darwin systems, arch arm64e means ARMv8.3 with p
https://github.com/clayborg commented:
Can we not just use a `Progress` object instead of installing a callback? Seems
like a very specific use case to install a callback for in our public API. Do
we create `Progress` objects for each background download? If we don't, should
we? Then this woul
https://github.com/clayborg edited
https://github.com/llvm/llvm-project/pull/82799
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
@@ -623,8 +630,20 @@ void Debugger::Terminate() {
}
if (g_thread_pool) {
-// The destructor will wait for all the threads to complete.
-delete g_thread_pool;
+// Delete the thread pool in a different thread so we can set a timeout.
clayborg wro
@@ -623,8 +630,20 @@ void Debugger::Terminate() {
}
if (g_thread_pool) {
-// The destructor will wait for all the threads to complete.
-delete g_thread_pool;
+// Delete the thread pool in a different thread so we can set a timeout.
JDevlieghere
JDevlieghere wrote:
> Can we not just use a `Progress` object instead of installing a callback?
> Seems like a very specific use case to install a callback for in our public
> API. Do we create `Progress` objects for each background download? If we
> don't, should we? Then this would show up i
@@ -0,0 +1,25 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestArm64eAttach(TestBase):
+NO_DEBUG_INFO_TESTCASE = True
+
+# On Darwin systems, arch arm64e means ARMv8.3 with p
@@ -0,0 +1,2 @@
+C_SOURCES := main.c
+include Makefile.rules
adrian-prantl wrote:
That is implicit. If you are running the tests with an arm64e ARCH, the test
will run (with that triple).
https://github.com/llvm/llvm-project/pull/82804
_
adrian-prantl wrote:
Would this change be observable by a test?
https://github.com/llvm/llvm-project/pull/82364
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
JDevlieghere wrote:
Greg and I talked this over offline. We both feel that progress events are the
best way to convey that work is going on in the background. To make that work
for the driver, we'll check if the debugger being destroyed is the very last
one and if it is, we'll delay its destru
https://github.com/adrian-prantl updated
https://github.com/llvm/llvm-project/pull/82804
>From d8e201683c460af42b671ecb433ba84620ada1c2 Mon Sep 17 00:00:00 2001
From: Adrian Prantl
Date: Fri, 23 Feb 2024 09:58:17 -0800
Subject: [PATCH] Replace ArchSpec::PiecewiseCompare() with
Triple::operator
https://github.com/JDevlieghere approved this pull request.
https://github.com/llvm/llvm-project/pull/82804
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
https://github.com/jasonmolenda updated
https://github.com/llvm/llvm-project/pull/82709
>From 171613d26338919e40584656a7f88899ba6cc5ca Mon Sep 17 00:00:00 2001
From: Jason Molenda
Date: Thu, 22 Feb 2024 15:35:31 -0800
Subject: [PATCH 1/2] [lldb] Correctly annotate threads at a bp site as hittin
@@ -1722,6 +1742,8 @@ ThreadSP ProcessGDBRemote::SetThreadStopInfo(
} else {
bool handled = false;
bool did_exec = false;
+ if (reason == "none")
jasonmolenda wrote:
I updated the patch where I handle this a little more cleanly, checking t
Author: Adrian Prantl
Date: 2024-02-23T14:00:15-08:00
New Revision: 25940956e68ec82d841e5748565e7250580e1d36
URL:
https://github.com/llvm/llvm-project/commit/25940956e68ec82d841e5748565e7250580e1d36
DIFF:
https://github.com/llvm/llvm-project/commit/25940956e68ec82d841e5748565e7250580e1d36.diff
https://github.com/adrian-prantl closed
https://github.com/llvm/llvm-project/pull/82804
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
jasonmolenda wrote:
> This seems safe to me, and it can't hurt to take care of this corner case
> here regardless of what the higher levels of lldb does.
This all falls under `Thread::CalculateStopInfo()` -
`ThreadGDBRemote::CalculateStopInfo` is calling into ProcessGDBRemote where we
do this
llvmbot wrote:
@llvm/pr-subscribers-backend-arm
@llvm/pr-subscribers-clang
Author: AtariDreams (AtariDreams)
Changes
Every once in a while, some formatting scanner will cause the CI to stop
because of whitespace issues, so it is is best to just remove them in one go,
especially since it
https://github.com/AtariDreams closed
https://github.com/llvm/llvm-project/pull/82838
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
AtariDreams wrote:
I'm just gonna split this up. Sorry.
https://github.com/llvm/llvm-project/pull/82838
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
github-actions[bot] wrote:
⚠️ We detected that you are using a GitHub private e-mail address to contribute
to the repo.
Please turn off [Keep my email addresses
private](https://github.com/settings/emails) setting in your account.
See [LLVM
Discourse](https://discourse.llvm.org/t/hidden-em
Author: Jason Molenda
Date: 2024-02-23T14:45:22-08:00
New Revision: 87fadb3929163752f650a1fc08d5fb13ee4c1a3f
URL:
https://github.com/llvm/llvm-project/commit/87fadb3929163752f650a1fc08d5fb13ee4c1a3f
DIFF:
https://github.com/llvm/llvm-project/commit/87fadb3929163752f650a1fc08d5fb13ee4c1a3f.diff
https://github.com/jasonmolenda closed
https://github.com/llvm/llvm-project/pull/82709
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
joker-eph wrote:
Fine with me if we want to land this as is, but per-top-level subproject may be
a better granularity.
https://github.com/llvm/llvm-project/pull/82838
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi
@@ -3944,15 +3955,22 @@ rnb_err_t RNBRemote::HandlePacket_v(const char *p) {
// The order of these checks is important.
if (process_does_not_exist (pid_attaching_to)) {
DNBLogError("Tried to attach to pid that doesn't exist");
- std::string
felipepiovezan wrote:
Juuust to make sure, was this discussed before? This seems akin to running
clang-format on the entire project, which last time we talked about still faced
opposition:
https://discourse.llvm.org/t/rfc-clang-format-all-the-things/76614/11
https://github.com/llvm/llvm-proje
Author: Adrian Prantl
Date: 2024-02-23T15:26:14-08:00
New Revision: 3f91bdfdd50aa4eaf1d3e49cf797220cfeccaf16
URL:
https://github.com/llvm/llvm-project/commit/3f91bdfdd50aa4eaf1d3e49cf797220cfeccaf16
DIFF:
https://github.com/llvm/llvm-project/commit/3f91bdfdd50aa4eaf1d3e49cf797220cfeccaf16.diff
@@ -3944,15 +3955,22 @@ rnb_err_t RNBRemote::HandlePacket_v(const char *p) {
// The order of these checks is important.
if (process_does_not_exist (pid_attaching_to)) {
DNBLogError("Tried to attach to pid that doesn't exist");
- std::string
arichardson wrote:
This will cause huge merge conflicts for all downstreams. While they are easy
to resolve it can be quite annoying. I think we should just do this as part of
the global clang-format.
https://github.com/llvm/llvm-project/pull/82838
_
jrtc27 wrote:
Also this is the kind of commit that should really be done by a core trusted
member of the community. It's way too easy to hide something nefarious (not
that I'm accusing you of that, just that we always need to be vigilant) in an
8k+ diff, and it's not much fun to review that co
dwblaikie wrote:
The dev policy says "Avoid committing formatting- or whitespace-only changes
outside of code you plan to make subsequent changes to." - I think it's
reasonable to consider changing this, but probably under the "clang-format
everything" or a similar discussion (broad discussion
@@ -3944,15 +3955,22 @@ rnb_err_t RNBRemote::HandlePacket_v(const char *p) {
// The order of these checks is important.
if (process_does_not_exist (pid_attaching_to)) {
DNBLogError("Tried to attach to pid that doesn't exist");
- std::string
https://github.com/jasonmolenda approved this pull request.
I haven't used the std::async feature before, but it looks reasonable. This
looks good to me.
https://github.com/llvm/llvm-project/pull/82799
___
lldb-commits mailing list
lldb-commits@lists
60 matches
Mail list logo
