Looks like I sent this to the wrong mailing list, and during the holiday season to boot.  Posting it to the right mailing list this time.<div><br></div><div>To add a little bit to my original post, I did end up finding a few more places where this is called.  In particular, in addition to the aforementioned tests, it also seems to be called in order to get the process's as a way to embed the application's input/output in the LLDB terminal.</div><div><br></div><div>With that said, I also want to add a 3rd question to my original list.  </div><div><br></div><div>3) Can we satisfy every use case of GetSTDOUT, GetSTDERR, and PutSTDIN with a different mechanism?  For example, stdio redirection of the target process.  Unless there is some use case of these functions that require LLDB to be able to manipulate a target's stdio *without* re-directing them (so that they are still hooked up to the standard terminal), then it seems like we should be ok in principle with just repurposing stdio redirection for this.</div><div><br></div><div>The reason I ask is that it is almost impossible (at the very least, it is extremely difficult) to implement this on Windows in such a way that LLDB can read / write to these streams without creating a pipe between LLDB and the target.  If there's a way to satisfy every platform that would be preferable.  If not, what feature set am I missing out on?<br><br><div class="gmail_quote">On Fri Nov 21 2014 at 5:46:46 PM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I only see these functions being called from a couple of tests so I wasn't able to figure out from the documentation all the preconditions and assumptions that these functions make.    So I have a few questions:<div><br></div><div>1) Does the use of these functions require or assume that the process is stopped at a breakpoint, or should they work even if the process is running?</div><div><br></div><div>2) When you call GetSTDOUT or GetSTDERR and they return successfully, does it matter whether this eats the output from the actual STDOUT / STDERR?</div><div><br></div><div>For example, let's say we are using the public API and we launch a process with STDOUT re-directed to a file.  Later, we call Process.GetSTDOUT using the public API, and the value is returned to our script.  Does the output that we read still need to go to the file?</div></blockquote></div></div>