Redirecting to a file is easy, and creating a pipe is easy.  The problem is that both of these will result in stdio to/from the actual terminal not happening anymore.  In other words, I can only easily have one or the other.  Either LLDB has access to the streams, or the terminal has access to the streams.  Not both.<br><br><div class="gmail_quote">On Wed Dec 03 2014 at 10:59:38 AM Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Dec 2, 2014, at 11:53 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> On Fri Nov 21 2014 at 5:46:46 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
> 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:<br>
><br>
> 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?<br>
<br>
they should work when the process is running. On Unix variants we use a pseudo terminal where we hold the master side and the debugged process gets the slave side of the pseudo terminal. When the debuggee writes to the slave side, we can immediately read it from the master side. Any files that you use to implement this need to be unbuffered and the stdio needs to be able to be delivered immediately down to the debuggee and also LLDB needs to be able to read the data as soon as it comes in.<br>
<br>
> 2) When you call GetSTDOUT or GetSTDERR and they return successfully, does it matter whether this eats the output from the actual STDOUT / STDERR?<br>
<br>
It should be consuming it from the actual file you are using to receive it (we consume the stdout/stderr by reading from the master_fd from the master side of the pseudo terminal). It probably isn't a good idea to not consume the data from stdout/stderr because you might fill up the stdio buffers and and subsequent writes to stdout/stderr can cause your program to deadlock with a full stdio buffer. The current implementation starts up a stdio read thread where it reads from stdout/stderr continuously and places anything it receives into Process::m_stdout_data or Process::m_stderr_data. These are protected by the m_stdio_communication_mutex so it is thread safe.<br>
<br>
><br>
> 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?<br>
<br>
You shouldn't get any stdout in lldb_private::Process if it was re-directed to a file. For example in unix, if we redirect only stdout to a file (not stderr or stdin), we would end up launching a child process with:<br>
<br>
stdin:  /dev/slave-pty-01<br>
stdout: /tmp/foo.txt<br>
stderr: /dev/slave-pty-01<br>
<br>
So the debugged process would be writing directly to /tmp/foo.txt and nothing should show up in the LLDB console.<br>
<br>
We would still startup a read thread for stderr (see Process::<u></u>SetSTDIOFileDescriptor (int fd)) and it currently has a bug where it doesn't separate stdout and stderr correctly (most people redirect both stdout/stderr or don't do it), so we should get that. But when redirecting stdout and stderr, we should never see anything in the LLDB console and if we redirect both stdout/stderr, we shouldn't be starting up a read thread via "Process::<u></u>SetSTDIOFileDescriptor (int fd)".<br>
<br>
<br>
> 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.<br>
><br>
> 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.<br>
><br>
> With that said, I also want to add a 3rd question to my original list.<br>
><br>
> 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.<br>
><br>
> 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>
It is very easy for unix and unix doesn't need to change. You will need to make this happen for windows. What is the problem with creating a pipe? Is there a reason you can't do this? What part is hard? Redirecting to a file? Or using live streams between LLDB and the inferior when stdio isn't redirected. IO redirection is a host layer thing that should be implemented in your Host::LaunchProcess(). Did you do any of the file redirection stuff in there? Or are you using a separate launching mechanism for debugging?</blockquote></div>