[all-commits] [llvm/llvm-project] 1eaa28: [lldb/Host] Enable inheriting "non-inheritable" FD...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1eaa289472aaddbeabcde10f89cffb161c2dca55
      https://github.com/llvm/llvm-project/commit/1eaa289472aaddbeabcde10f89cffb161c2dca55
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2025-05-06 (Tue, 06 May 2025)

  Changed paths:
    M lldb/source/Host/macosx/objcxx/Host.mm
    M lldb/source/Host/posix/ProcessLauncherPosixFork.cpp
    M lldb/unittests/Host/HostTest.cpp

  Log Message:
  -----------
  [lldb/Host] Enable inheriting "non-inheritable" FDs (#126935)

Currently we're creating inheritable (`~FD_CLOEXEC`) file descriptors in
the (few) cases where we need to pass an FD to a subprocess. The problem
with these is that, in a multithreaded application such as lldb, there's
essentially no way to prevent them from being leaked into processes
other than the intended one.

A safer (though still not completely safe) approach is to mark the
descriptors as FD_CLOEXEC and only clear this flag in the subprocess. We
currently have something that almost does that, which is the ability to
add a `DuplicateFileAction` to our `ProcessLaunchInfo` struct (the
duplicated file descriptor will be created with the flag cleared). The
problem with *that* is that this approach is completely incompatible
with Windows.

Windows equivalents of file descriptors are `HANDLE`s, but these do not
have user controlled values -- applications are expected to work with
whatever HANDLE values are assigned by the OS. In unix terms, there is
no equivalent to the `dup2` syscall (only `dup`).

To find a way out of this conundrum, and create a miniscule API surface
that works uniformly across platforms, this PR proposes to extend the
`DuplicateFileAction` API to support duplicating a file descriptor onto
itself. Currently, this operation does nothing (it leaves the FD_CLOEXEC
flag set), because that's how `dup2(fd, fd)` behaves, but I think it's
not completely unreasonable to say that this operation should clear the
FD_CLOEXEC flag, just like it would do if one was using different fd
values. This would enable us to pass a windows HANDLE as itself through
the ProcessLaunchInfo API.

This PR implements the unix portion of this idea. Macos and non-macos
launchers are updated to clear FD_CLOEXEC flag when duplicating a file
descriptor onto itself, and I've created a test which enables passing a
FD_CLOEXEC file descritor to the subprocess. For the windows portion,
please see the follow-up PR.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications