[Lldb-commits] [lldb] [lldb] Inherit DuplicateFileAction(HANDLE, HANDLE) handles on windows (PR #137978)

[Pavel Labath via lldb-commits]

================
@@ -274,10 +274,8 @@ static Status spawn_process(const char *progname, const FileSpec &prog,
   self_args.AppendArgument(llvm::StringRef("platform"));
   self_args.AppendArgument(llvm::StringRef("--child-platform-fd"));
   self_args.AppendArgument(llvm::to_string(shared_socket.GetSendableFD()));
-#ifndef _WIN32
   launch_info.AppendDuplicateFileAction((int)shared_socket.GetSendableFD(),
                                         (int)shared_socket.GetSendableFD());
----------------
labath wrote:

I don't understand what's the problem with that. I'm pretty sure that zero is not a valid handle value (https://devblogs.microsoft.com/oldnewthing/20040302-00/?p=40443), so it can't conflict with STDIN_FILENO.

Relatedly, I had an idea which might alleviate some of your concerns. While I firmly believe that getting right of the `child_process_inherit` constructor argument is the right thing to do, I'm not entirely happy that this results in making *all* pipe handles inheritable. In the description I propose creating a helper function which creates a copy of the handle which can be inherited. On windows this would call `DuplicateHandle` with `bInheritHandle=TRUE` and on posix it would be a no-op (as we're able to change the CLOEXEC flag on the fd later).

If we had that, we could also easily ensure that the returned handle does not conflict with our "reserved" values -- if `DuplicateHandle` returns 0/1/2, just call it again until it returns something bigger. It's kinda gross, but I also somehow like it :P

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