[Lldb-commits] [lldb] [lldb/Host] Enable inheriting "non-inheritable" FDs (PR #126935)

[David Spickett via lldb-commits]

================
@@ -122,8 +123,14 @@ struct ForkLaunchInfo {
         ExitWithError(error_fd, "close");
       break;
     case FileAction::eFileActionDuplicate:
-      if (dup2(action.fd, action.arg) == -1)
-        ExitWithError(error_fd, "dup2");
+      if (action.fd != action.arg) {
+        if (dup2(action.fd, action.arg) == -1)
+          ExitWithError(error_fd, "dup2");
+      } else {
+        if (fcntl(action.fd, F_SETFD,
+                  fcntl(action.fd, F_GETFD) & ~FD_CLOEXEC) == -1)
----------------
DavidSpickett wrote:

https://man7.org/linux/man-pages/man2/dup.2.html

> The two file descriptors do not share file descriptor flags (the
>  close-on-exec flag).  The close-on-exec flag (FD_CLOEXEC; see
 >  [fcntl(2)](https://man7.org/linux/man-pages/man2/fcntl.2.html)) for the duplicate descriptor is off.

So regardless of the value of FD_CLOEXEC for action.fd, action.arg will always have FD_CLOEXEC not set.

So action.fd != action.arg makes sense to me. action.arg cannot make it past the exec if we don't clear the flag.

Same applies if action.fd == action.arg, if action.fd has FD_CLOEXEC set, it must be cleared.

So both are doing the same thing, but you need to make a new descriptor in one case.

Still wondering what the logic of setting FD_CLOEXEC or not in the first place is, and whether you'd want to set it in the process you have just exec'd into.

In other words: is it a problem that the new file descriptor in the new process will not have FD_CLOEXEC set? Because I assume someone set this flag for some reason in the original process.

https://github.com/llvm/llvm-project/pull/126935