This is an archive of the discontinued LLVM Phabricator instance.

Propagate FORK events back to client
Needs RevisionPublic

Authored by irinasha on Sep 26 2022, 6:34 AM.

Details

Reviewers
jingham
labath
Summary

We want to allow the client to detect when the 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:

  • stop-on-clone-events (false/true);
  • detach-keeps-stopped (false/true).

The client (IDE in our case) can then decide to attach another debugger to that process.

  • By default these options will be disabled, so the default behavior won't change.

Diff Detail

Event Timeline

irinasha created this revision.Sep 26 2022, 6:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 26 2022, 6:34 AM
Herald added a subscriber: emaste. · View Herald Transcript
irinasha requested review of this revision.Sep 26 2022, 6:34 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 26 2022, 6:34 AM
irinasha retitled this revision from Propagate FORK events back to client to Propagate FORK events back to client (WIP).Sep 26 2022, 6:36 AM
irinasha added a subscriber: werat.
irinasha changed the visibility from "Public (No Login Required)" to "No One".Sep 26 2022, 7:46 AM
irinasha updated this revision to Diff 462949.Sep 26 2022, 9:49 AM
irinasha updated this revision to Diff 463099.Sep 26 2022, 11:33 PM

Failed to apply the patch

irinasha changed the visibility from "No One" to "Public (No Login Required)".Sep 26 2022, 11:39 PM
irinasha retitled this revision from Propagate FORK events back to client (WIP) to Propagate FORK events back to client.Sep 30 2022, 1:14 AM
irinasha added reviewers: jingham, labath.
jingham requested changes to this revision.Jan 10 2023, 4:59 PM

First off, Is there a meaningful distinction between "fork" and "clone" in this context? we call the act whereby a process generates a child process a fork everywhere else in lldb (e.g. in follow-fork-mode) so unless "clone" really does mean something different from fork, it's confusing to have this setting use "clone".

This patch seems to be two orthogonal pieces. One is adding the "detach and keep stopped" capability to the NativeProcess classes. That part seems fine to me, and fairly uncontroversial. This is useful behavior independently of whether the any forks went on or not. This part could really be a separate patch on its own.

And the other piece is to stop or not on fork events. That also seems like a generally useful ability, but I'm a little unclear on how this interacts with follow-fork-mode. If I'm following into the child, and I stop on the event, will I stop in the child already? Or does it stop before, then when you "continue" you'll end up switching to the child? If I stop at the fork event, then set "follow-fork-mode" to follow into the child and continue, will I end up in the child? Seems like we should know how we think that's going to go, and test the various different combinations to ensure that behavior.

This revision now requires changes to proceed.Jan 10 2023, 4:59 PM

Note, IMO the better solution to the problem of how to follow parent & child over a fork is to implement another "follow-fork" mode: "both" that when it sees the fork event, creates a separate target for the child process, and sets lldb debugging both. Then the user could set in a setting what they want to do, and lldb would just take care of it for them. But that's a bigger job than this.