[RFC] Support debugging child processes

Subprojects LLDB
1

TL;DR

We want to allow the client to detect when the debugged process forks and to attach the debugger to a newly created process. For this we propose to implement two options in LLDB: to propagate fork/vfork events to the client and to automatically detach the child/parent in a stopped state. The client can then decide to attach another debugger to that process. Here’s a proof-of-concept implementation – ⚙ D134642 Propagate FORK events back to client.

Motivation

In our extension for Microsoft Visual Studio we use LLDB as a debugger backend (GitHub - googlestadia/vsi-lldb). We’d like to support automatic debugging of child processes. We are aware of an effort to support the multi-process debugging directly in LLDB (discussion), but we want to propose a complementary approach that is easier to implement and may be more convenient to use from the client perspective.

Proposal

In order to achieve the described behavior, we propose to implement two changes in LLDB:

  1. Add an option stop-on-clone-events to propagate the following events to the client: fork, vfork, vfork_done
  2. Add an option detach-keeps-stopped (already exists in LLDB) to detach the child/parent process in a stopped state
    • On Linux this can be implemented in lldb-server by injected SIGSTOP via PT_DETACH

The combination of these two options will allow the client to detect when the debugged process forks and then immediately start another debugging session for the detached process. The client (IDE in our case) will manage multiple debugging sessions and from the user perspective it would be completely transparent. By default these options will be disabled, so the default behavior won’t change.

Note: the support for detaching the process in a stopped state is already declared in the Process.h, but it’s not implemented.

1 Like
RFC: lldb-vscode startDebugging reverse requests
LLVM Weekly - #456, September 26th 2022
2

I can’t see the proof of concept review, I get some access denied error…

These seem reasonable behaviors.

At some point, lldb will also support following both sides of the fork (auto-creating a Target for the child). In that case, you will also want to be able to say whether the new target’s process should be left stopped or allowed to run after the fork detection. That’s logically the same sort of decision you are making with detach-keeps-stopped so I wonder if there’s a way to phrase the setting name so it can be used for both cases (and thus we can avoid adding another setting - we have a lot already.)

3

I’ve temporarily disabled the CL, the build was failing due to some problem in the patch. It’s fixed now :slight_smile:
Thank you for looking into this