Feel free to do what you need to to make this happen. Not sure why both can't coexist. What is the hinderance?
> On Dec 3, 2014, at 11:04 AM, Zachary Turner <ztur...@google.com> wrote: > > 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. > > On Wed Dec 03 2014 at 10:59:38 AM Greg Clayton <gclay...@apple.com> wrote: > > > On Dec 2, 2014, at 11:53 PM, Zachary Turner <ztur...@google.com> wrote: > > > > On Fri Nov 21 2014 at 5:46:46 PM Zachary Turner <ztur...@google.com> wrote: > > 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: > > > > 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? > > 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. > > > 2) When you call GetSTDOUT or GetSTDERR and they return successfully, does > > it matter whether this eats the output from the actual STDOUT / STDERR? > > 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. > > > > > 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? > > 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: > > stdin: /dev/slave-pty-01 > stdout: /tmp/foo.txt > stderr: /dev/slave-pty-01 > > So the debugged process would be writing directly to /tmp/foo.txt and nothing > should show up in the LLDB console. > > We would still startup a read thread for stderr (see > Process::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::SetSTDIOFileDescriptor (int fd)". > > > > 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. > > > > 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. > > > > With that said, I also want to add a 3rd question to my original list. > > > > 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. > > > > 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? > > 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? _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
