================
@@ -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
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
