We already have one piece of "status" parsing code in source/Host/linux/Host.cpp. I think it'd be better to reuse that one. I'm slightly torn as to whether reuse Host::GetProcessInfo for this (and add a new field to ProcessInstanceInfo -- or possibly expand on IsZombie), or whether to create a new linux-specific entry point which will return this data.

Some caveats that I need to address before we publish this PR is how to prevent LLDB from running any expressions or really anything that trys to SIGCONT, because that will immediately terminate the process, I would like this behavior to mimic how we inform the user post mortem processes can't run expressions.

I don't know the answer to that, but I can say that I don't think this feature needs to be (or should be) specific to this use case. One of the things that I would like to be able to do is to stop a process right before it exits (regardless of whether that's through the exit syscall, or a fatal signal, etc.). PTRACE_O_TRACEEXIT lets you do that, but it means the process will end up in the same "almost a zombie" state, where any attempt to resume it will cause it to disappear. If we had a mechanism to prevent this, we could use it in this case as well. (and this case, unlike this "dead" state, is actually testable).

I think the tricky part is that (in both cases) the user might legitimately want to let the process exit, and "continue" is the normal way to do that, so I don't think we'd want to just error out of the continue command (or from the vCont packet). I think what we'd want is to make sure that the process doesn't accidentally exit while running an expression (possibly from within a data formatter), and for that I guess we'd need to let lldb know that running expressions is "dangerous". We already have Thread::SafeToCallFunctions, even though it's used for a slightly different purpose, but maybe it could be extended to handle this as well?

I think the tricky part is that (in both cases) the user might legitimately want to let the process exit, and "continue" is the normal way to do that, so I don't think we'd want to just error out of the continue command (or from the vCont packet). I think what we'd want is to make sure that the process doesn't accidentally exit while running an expression (possibly from within a data formatter), and for that I guess we'd need to let lldb know that running expressions is "dangerous". We already have Thread::SafeToCallFunctions, even though it's used for a slightly different purpose, but maybe it could be extended to handle this as well?

I think disallowing any non explicit continues/disconnect is a good user experience as long as we display an appropriate message. The workflow I imagine is when halted in this state any explicit continue or disconnect should just kill the process, but something like p MyVar.Size() should not.

We already have one piece of "status" parsing code in source/Host/linux/Host.cpp. I think it'd be better to reuse that one. I'm slightly torn as to whether reuse Host::GetProcessInfo for this (and add a new field to ProcessInstanceInfo -- or possibly expand on IsZombie), or whether to create a new linux-specific entry point which will return this data.

Will refactor, I looked for something for status and it seems I missed something

I see this is still a draft, but to avoid surprised, I want to say that I think this should be two or three patches in the final form. One for the PTRACE_SEIZE thingy, one for the "mechanism to prevent a process from resuming" and maybe (depending on how involved it gets) one for refactoring the /proc/status parser.

I see this is still a draft, but to avoid surprised, I want to say that I think this should be two or three patches in the final form. One for the PTRACE_SEIZE thingy, one for the "mechanism to prevent a process from resuming" and maybe (depending on how involved it gets) one for refactoring the /proc/status parser.

I'm okay with that, I'm still in the 'experiment and see what happens phase' when it comes to preventing continue.

How does this proposal sound:

• SEIZE + Parsing Proc Status
• GDB Server changes to prevent resumption
• Move the Proc Status (not stat) code to the HOST class

For #3, I think it's got some loose scope around if it should replace proc stat or be in addition to it. The biggest complexity here is we're adding information into qProcessInfo that isn't exclusively about the process but now about how we're interacting with the process. So I think tackling that as it's own step makes sense.

Also if/when you commit parts of this, please include a version of the example gist in one of the commit messages, it might be useful in future.

This is pretty complicated to test because it requires integration with the Kernel

Can you make the same thing happen without using a coredumper? I feel like the answer is a solid no but I'm not sure why.

Another way we can do it is to write a test that checks that if the remote says it's in a non-resumable state, we act in a certain way. Only half the story but it's something.

Move the Proc Status (not stat) code to the HOST class

I'd put this first (in which case it wouldn't be called "move" but "extend" or "refactor"), for two reasons:

• it reduces the chance of ending up with two parsers
• I'm not very happy with the implementation you have here. I think using structured data is overkill and makes using it more complicated. Since this is an internal API, and we don't have to worry about stability, I think a struct with a bool field (or optional<bool> if you need to treat "not present" differently) would be better. (That's also more-or-less what the existing implementation does)

@llvm/pr-subscribers-lldb

Author: Jacob Lalonde (Jlalond)

diff --git a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
index 7f2aba0e4eb2c..141e49d8a0b7e 100644
--- a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -312,10 +312,26 @@ NativeProcessLinux::Manager::Attach(
   Log *log = GetLog(POSIXLog::Process);
   LLDB_LOG(log, "pid = {0:x}", pid);
 
-  auto tids_or = NativeProcessLinux::Attach(pid);
-  if (!tids_or)
-    return tids_or.takeError();
-  ArrayRef<::pid_t> tids = *tids_or;
+  // This safety check lets us decide if we should
+  // seize or attach.
+  ProcessInstanceInfo process_info;
+  if (!Host::GetProcessInfo(pid, process_info))
+    return llvm::make_error<StringError>("Unable to read process info",
+                                         llvm::inconvertibleErrorCode());
+
+  std::vector<::pid_t> tids;
+  if (process_info.IsCoreDumping()) {
+    auto attached_or = NativeProcessLinux::Seize(pid);
+    if (!attached_or)
+      return attached_or.takeError();
+    tids = std::move(*attached_or);
+  } else {
+    auto attached_or = NativeProcessLinux::Attach(pid);
+    if (!attached_or)
+      return attached_or.takeError();
+    tids = std::move(*attached_or);
+  }
+
   llvm::Expected<ArchSpec> arch_or =
       NativeRegisterContextLinux::DetermineArchitecture(tids[0]);
   if (!arch_or)
@@ -444,6 +460,88 @@ NativeProcessLinux::NativeProcessLinux(::pid_t pid, int terminal_fd,
   SetState(StateType::eStateStopped, false);
 }
 
+llvm::Expected<std::vector<::pid_t>> NativeProcessLinux::Seize(::pid_t pid) {
+  Log *log = GetLog(POSIXLog::Process);
+
+  uint64_t options = GetDefaultPtraceOpts();
+  Status status;
+  // Use a map to keep track of the threads which we have attached/need to
+  // attach.
+  Host::TidMap tids_to_attach;
+  while (Host::FindProcessThreads(pid, tids_to_attach)) {
+    for (Host::TidMap::iterator it = tids_to_attach.begin();
+         it != tids_to_attach.end();) {
+      if (it->second == true) {
+        continue;
+      }
+      lldb::tid_t tid = it->first;
+      if ((status = PtraceWrapper(PTRACE_SEIZE, tid, nullptr, (void *)options))
+              .Fail()) {
+        // No such thread. The thread may have exited. More error handling
+        // may be needed.
+        if (status.GetError() == ESRCH) {
+          it = tids_to_attach.erase(it);
+          continue;
+        }
+        if (status.GetError() == EPERM) {
+          // Depending on the value of ptrace_scope, we can return a
+          // different error that suggests how to fix it.
+          return AddPtraceScopeNote(status.ToError());
+        }
+        return status.ToError();
+      }
+
+      if ((status = PtraceWrapper(PTRACE_INTERRUPT, tid)).Fail()) {
+        // No such thread. The thread may have exited. More error handling
+        // may be needed.
+        if (status.GetError() == ESRCH) {
+          it = tids_to_attach.erase(it);
+          continue;
+        }
+        if (status.GetError() == EPERM) {
+          // Depending on the value of ptrace_scope, we can return a
+          // different error that suggests how to fix it.
+          return AddPtraceScopeNote(status.ToError());
+        }
+        return status.ToError();
+      }
+
+      int wpid =
+          llvm::sys::RetryAfterSignal(-1, ::waitpid, tid, nullptr, __WALL);
+      // Need to use __WALL otherwise we receive an error with errno=ECHLD At
+      // this point we should have a thread stopped if waitpid succeeds.
+      if (wpid < 0) {
+        // No such thread. The thread may have exited. More error handling
+        // may be needed.
+        if (errno == ESRCH) {
+          it = tids_to_attach.erase(it);
+          continue;
+        }
+        return llvm::errorCodeToError(
+            std::error_code(errno, std::generic_category()));
+      }
+
+      LLDB_LOG(log, "adding tid = {0}", tid);
+      it->second = true;
+
+      // move the loop forward
+      ++it;
+    }
+  }
+
+  size_t tid_count = tids_to_attach.size();
+  if (tid_count == 0)
+    return llvm::make_error<StringError>("No such process",
+                                         llvm::inconvertibleErrorCode());
+
+  std::vector<::pid_t> tids;
+  tids.reserve(tid_count);
+  for (const auto &p : tids_to_attach)
+    tids.push_back(p.first);
+
+  return std::move(tids);
+}
+
 llvm::Expected<std::vector<::pid_t>> NativeProcessLinux::Attach(::pid_t pid) {
   Log *log = GetLog(POSIXLog::Process);
 
@@ -513,8 +611,8 @@ llvm::Expected<std::vector<::pid_t>> NativeProcessLinux::Attach(::pid_t pid) {
   return std::move(tids);
 }
 
-Status NativeProcessLinux::SetDefaultPtraceOpts(lldb::pid_t pid) {
-  long ptrace_opts = 0;
+uint64_t NativeProcessLinux::GetDefaultPtraceOpts() {
+  uint64_t ptrace_opts = 0;
 
   // Have the child raise an event on exit.  This is used to keep the child in
   // limbo until it is destroyed.
@@ -537,6 +635,11 @@ Status NativeProcessLinux::SetDefaultPtraceOpts(lldb::pid_t pid) {
   // the child finishes sharing memory.
   ptrace_opts |= PTRACE_O_TRACEVFORKDONE;
 
+  return ptrace_opts;
+}
+
+Status NativeProcessLinux::SetDefaultPtraceOpts(lldb::pid_t pid) {
+  uint64_t ptrace_opts = GetDefaultPtraceOpts();
   return PtraceWrapper(PTRACE_SETOPTIONS, pid, nullptr, (void *)ptrace_opts);
 }
 
diff --git a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.h b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
index d345f165a75d8..9ae4e57e74add 100644
--- a/lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ b/lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -175,7 +175,6 @@ class NativeProcessLinux : public NativeProcessELF,
 private:
   Manager &m_manager;
   ArchSpec m_arch;
-
   LazyBool m_supports_mem_region = eLazyBoolCalculate;
   std::vector<std::pair<MemoryRegionInfo, FileSpec>> m_mem_region_cache;
 
@@ -191,9 +190,13 @@ class NativeProcessLinux : public NativeProcessELF,
 
   // Returns a list of process threads that we have attached to.
   static llvm::Expected<std::vector<::pid_t>> Attach(::pid_t pid);
+  // Returns a list of process threads that we have seized and interrupted.
+  static llvm::Expected<std::vector<::pid_t>> Seize(::pid_t pid);
 
   static Status SetDefaultPtraceOpts(const lldb::pid_t);
 
+  static uint64_t GetDefaultPtraceOpts();
+
   bool TryHandleWaitStatus(lldb::pid_t pid, WaitStatus status);
 
   void MonitorCallback(NativeThreadLinux &thread, WaitStatus status);

@labath @DavidSpickett Thanks for the patience.

I've broken down my prototype, and this is now patch 2, where we implement the SEIZE functionality. I will follow up with making it so we can't resume the process when we're in this state.

@DavidSpickett you mentioned you wanted me to include my gist, to my knowledge github will include my summary by default. Did you want me to check in the toy program as an example?

You can include your gist content in the PR summary, I've certainly seen longer commit messages than that in llvm :)

The question I want to be able to answer from the final commit message is "what is a dead process and how do I make one?". So that in future if I need to investigate this code, I know where to start. You can do that by linking to well established documentation on the subject, or writing it in your own words, and/or including that example.

If we are able to construct a test case, that would serve the same purpose.

Also FYI this has CI failures, https://buildkite.com/llvm-project/github-pull-requests/builds/177176#0196b180-e7c0-49e9-99ac-65dcc8a3c1a9, not sure if you are aware.

LLDB isn't known for being super stable in pre-commit CI, but they are on the same topic as this.

@DavidSpickett fixed the test, I gotcha'd myself checking an optional of a bool. I added my gist to the description, let me know what you think

I added my gist to the description, let me know what you think

This part looks good, that'll be enough to test this / explain why it exists.

What do you say to all this? I realize I am sort of asking you my pet feature, but I think that by framing your feature (debugging of dead processes) as a special case of this (debugging exiting processes), we can avoid most of the problematic issues with this PR (divergence of implementation, impossibility of testing).

I'm in! I always thought this was a great segue for PTRACE_O_TRACEEXIT as a feature. We recently had someone else leave our team and I'm diverting to finish up some of the ELF Core work (hence you've seen my patches), but once I get that wrapped up I'll be back working on this.

✅ With the latest revision this PR passed the C/C++ code formatter.

@labath I'm back to working on this!

My only questions are going to be aligning on implementation. Currently today we effectively ignore the stops from trace_exit (despite setting the option), leveraging the event mostly to clean up the program.

I think we have two approaches, I'm open to either but I may be ignorant to some details about the gdb remote protocol.

1. We return a process info whenever we attach, we could return the flag for coredumping here and let the GDB remote client know that this process is not safe to resume, only to be exited. We can also set CanJit false to prevent trying to Jit in the zombie state. In the future we could extend this to send the trace_exit state and do the same, dependent on some setting.

2. We have the gdb server send a packet if it's safe to resume. I'm pretty ignorant about this but it lets us keep the process logic in gdb-server which I do appreciate. My concern here is we'd need to propagate some user setting and I'm unsure or unaware how to do that, code pointers would be appreciated.

Assuming we have an extant system to send settings I prefer option 2, option 1 is similar to how I landed my internal patch when I first attempted this. @DavidSpickett I'd also appreciate your insight

Sorry about the delay. I'm not sure I understand the question, but the way I'm imagining this is to let the server communicate the "is it safe to resume" bit to the client. After that, the client can do whatever it wants/needs (e.g. disable jitting/expression evaluation).

I think this is closest to your option one, except that I would make this a per-thread property, for example via a new field in the qThreadStopInfo packet. Then, the core-dumping process would just be special case of a process whose all threads are exiting.

I'm not sure I understand the second option, but we don't really have a way for the server to send unsolicited packets to the client -- but I also don't see why we would need to send them.

As for the "in the future" part, I think it would be easier to implement most of that feature now, because:

• that feature (unlike core dumping) is testable
• it requires solving most of the same problems, like how do we prevent from resuming the application unintentionally, and how do we let the user know that the application is in this non-resumable state

The only extra thing we'd need to solve for that is how does the user actually request that the application stops before exiting -- and I'd be fine if we postponed the creation of the UI for that. However, that doesn't mean we can't create some sort of a back door for testing. For example, we can add a new packet to lldb-server (QEnableExitStops?), but don't hook it up to any user-facing commands. The tests (and power users) can still access it via the "process plugin packet" command. The test for handling of this state would consist of sending this packet, resuming the application and then waiting for it to stop in the "pre-exit" state. A core dumping process would just be a special case which is in the pre-exit state immediately after attaching.