[lldb-dap] Always stop on enrty for attaching

Recently upon debugging a program with thousands of threads, lldb-dap would hang at a `threads` request sent right after receiving the `configurationDone` response. Soon after it will end the debug session with "Process <pid> ex
ited with status = -1 (0xffffffff) lost connection".

This is because LLDB is still in the middle of resuming all the threads. And requesting threads will require stopp
ing the process. From the gdb-remote log it ended up getting `lldb::StateType::eStateInvalid` and just exit with s
tatus -1.

I don't think it's reasonable to allow getting threads from a running process. The alternative will be reject the
`threads` request if the process is not stopped.

Author: kusmour

lldb/test/API/tools/lldb-dap/attach/multithreading.cpp

@@ -0,0 +1,102 @@
+#include <condition_variable>
+#include <functional>
+#include <iostream>
+#include <mutex>
+#include <queue>
+#include <thread>
+
+int plus_one(int n) {
+  std::cout << "In plus_one" << std::endl;
+  return n + 1;
+}
+
+class ThreadPool {
+ public:
+  ThreadPool(size_t num_threads = std::thread::hardware_concurrency()) {
+    for (uint32_t i = 0; i < num_threads; ++i) {
+      threads.emplace_back(std::thread(&ThreadPool::ThreadLoop, this));
+    }
+  }
+  ~ThreadPool() {
+    {
+      std::unique_lock<std::mutex> lock(queue_mutex);
+      terminated = true;
+    }
+    condition.notify_all();
+    for (std::thread& thread : threads) {
+      thread.join();
+    }
+  }
+  void enqueue(const std::function<void()>& job) {
+    {
+      std::unique_lock<std::mutex> lock(queue_mutex);
+      if (terminated)
+        throw std::runtime_error("enqueue on stopped ThreadPool");
+      jobs.push(job);
+    }
+    condition.notify_one();
+  }
+
+ private:
+  void ThreadLoop() {
+    while (true) {
+      std::function<void()> job;
+      {
+        std::unique_lock<std::mutex> lock(queue_mutex);
+        condition.wait(lock, [this] { return !jobs.empty() || terminated; });
+        if (terminated && jobs.empty())
+          return;
+        job = jobs.front();
+        jobs.pop();
+      }
+      job();
+    }
+  }
+
+  bool terminated = false;
+  std::mutex queue_mutex;
+  std::condition_variable condition;
+  std::vector<std::thread> threads;
+  std::queue<std::function<void()>> jobs;
+};
+
+void thread_func(int job_index) {
+  std::cout << __FUNCTION__ << " (job index = " << job_index
+            << ") running on thread " << std::this_thread::get_id() << "\n";
+  std::cout << "Calling function plus_one(int)\nResult = "
+            << plus_one(job_index) << "\n";
+}
+
+void thread_sleep(int job_index, int sleep_sec) {
+  std::cout << __FUNCTION__ << " (job index = " << job_index
+            << ") starting on thread " << std::this_thread::get_id() << "\n";
+  std::this_thread::sleep_for(std::chrono::seconds(sleep_sec));
+  std::cout << __FUNCTION__ << " (job index = " << job_index
+            << ") finished on thread " << std::this_thread::get_id() << "\n";
+}
+
+int main() {
+  ThreadPool tp1(2000);
+  ThreadPool tp2;
+  std::cout << "main() running on thread " << std::this_thread::get_id()
+            << "\n";
+  std::cout
+      << "Program is expecting stdin. Please attach debugger and hit enter to continue\n";
+  std::cin.get();
+  // At least one of the thread in tp1 will be sceduled with a task twice or
+  // more if num_jobs is larger than #threads in tp1.
+  int num_jobs = 3000;
+  for (int i = 0; i < num_jobs; ++i) {
+    tp1.enqueue(std::bind(thread_func, i));
+  }
+  // We may or may not hit the breakpoint thread_sleep here, as the tread pool
+  // might finish executing before debugger release the bp for tp1.
+  // To make sure we hit the bp, we can increase the sleep time in the call.
+  for (int i = 0; i < num_jobs; ++i) {
+    tp2.enqueue([i] { thread_sleep(i, 1); });
+  }
+  for (int i = 0; i < num_jobs; ++i) {
+    tp1.enqueue(std::bind(thread_sleep, i, 1));
+    return 0;
+  }
+}

lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp

@@ -73,9 +73,11 @@ void AttachRequestHandler::operator()(const llvm::json::Object &request) const {
   llvm::StringRef core_file = GetString(arguments, "coreFile").value_or("");
   const uint64_t timeout_seconds =
       GetInteger<uint64_t>(arguments, "timeout").value_or(30);
-  dap.stop_at_entry = core_file.empty()
-                          ? GetBoolean(arguments, "stopOnEntry").value_or(false)
-                          : true;
+  // Clients like VS Code sends threads request right after receiving
+  // configurationDone reponse where the process might be resuming.
+  // Getting threads list on a running process is not supported by LLDB.
+  // Always stop the process after attaching.
+  dap.stop_at_entry = true;
   dap.configuration.postRunCommands = GetStrings(arguments, "postRunCommands");
   const llvm::StringRef debuggerRoot =
       GetString(arguments, "debuggerRoot").value_or("");