labath added a comment. I don't actually use vscode, so I don't really know whether this is a good idea, but if you say it is then I can go with that.
However, I think the implementation needs a lot of work: - it is very windows-hostile: `dup`, `pipe`, `select`, etc. don't exist or don't work on windows (btw, doing a blocking select before a blocking read is completely useless -- you might as well just do the read alone) - the lack of synchronization between the (detached) forwarding threads makes it very prone to crashes if something happens to write to stderr during shutdown or early in initialization The way I would imagine doing this is: - redirect stdout/err as early as possible to avoid something writing to it, but don't forward anything yet - when things are sufficiently initialized, start up the forwarding machinery - at, an appropriate point during shutdown, stop forwarding The stop forwarding is the trickiest part I think the most portable solution would be to just close the write end of the pipe, and join the forwarding thread (which will exit once read returns EOF). We should also think about testing all of this. Do we have a reliable mechanism to produce stdout/err output from lldb? I guess it the worst case we could try debugging a module which produces one of these warnings. Or, if this output is going to the same place as the SBDebuggers notion of stdout/err, then we could just stop calling `SetOutputFileHandle`, and have everything flow through this. That would reduce the overall complexity and would ensure this path gets better coverage, as it would be used in the common case instead of just for printing random errors. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80659/new/ https://reviews.llvm.org/D80659 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
