================
@@ -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:
> It is safe to truncate the handle (when passing it from 64-bit to 32-bit) or
> sign-extend the handle (when passing it from 32-bit to 64-bit)
That's interesting. Thanks for digging that up.
> But we must work with FileAction more clearly.
I would love to do that, but I really don't know how to do that (even if I had
the time to implement it, which I don't). Most of the FileAction just don't
make sense on windows. It doesn't make sense for these to talk about FDs, as
FDs aren't OS concepts. But even for handles, something like
`AppendOpenFileAction` doesn't make sense since you can't control the handle
value that gets assigned to that file.
The complicating factors are:
- this class isn't used only for host launches, but for remote targets as well,
which makes it perfectly reasonable to say something like
`AppendOpenFileAction(47, "/my/file")` even on a windows machine -- *if* you
end up launching the process on a unix system.
- The class itself doesn't know if it's going to be used for launching a
windows or unix process
- The API of this class is exposed via SBLaunchInfo, which makes it hard to
make changes to it (I mean you can, but then you have to have some sort of a
translation layer in SBLaunchInfo.
This is why something like a union or host-dependent type (which shared_fd_t
is) would be hard to implement and why the windows launcher uses STDERR_FILENO
(which, on windows, it's an [lldb
invention](https://github.com/llvm/llvm-project/blob/d6dbe7799e638702309e23fc7b73d4be2231e2ac/lldb/include/lldb/Host/windows/PosixApi.h#L85)).
It's not that the code tries to use 2 as a file descriptor -- it's trying to
make sense of what it was told by code assuming posix.
Of course, that's not what I do here. I am passing the handles as-is, which is
definitely different from using make up file identifiers, but with the right
amount of squinting, you could say this is consistent: For windows, the "fd"
arguments refer to HANDLEs, and 0/1/2 are special names for. I haven't been
able to find a definitive source for this (and that's probably because they
don't want to commit to it), but based on my experimentation browsing (e.g.
https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-handle)
and talking to AI, I got the impression that HANDLEs are always a multiple of
4, which means there should be no conflict with the fake handles.
https://github.com/llvm/llvm-project/pull/137978
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
