process launch -o /tmp/foo.out

Hi all,

I’m trying to get the test suite running against a Linux x86_64->Linux x86_64 remote target. I’m getting a failure when process launch is called with stdout redirected to a file.

The host is sending QSetSTDOUT to the remote host with a path that is only valid on the host.

For stdout/stderr there are a couple of ways to approach this problem.

  1. Let the inferior write to a temporary file on the remote host and then retrieve after the process exits? I don’t like this because I think it’s really useful to see the debug output from the file during debugging.

  2. Hand the inferior a pipe for each redirected stdout/stderr, transfer the bytes written to the host and then write them on the host to the specified file. What messages do I use for this? It should be independent of $O. I don’t want to use the $F messages because they’re slightly different (and a lot of work).

  3. ???

For stdin, I think I will just copy to file over to the target and open it on the inferior.

Thoughts?

Vince

Hi all,

I'm trying to get the test suite running against a Linux x86_64->Linux x86_64 remote target. I'm getting a failure when process launch is called with stdout redirected to a file.

The host is sending QSetSTDOUT to the remote host with a path that is only valid on the host.

For stdout/stderr there are a couple of ways to approach this problem.

1) Let the inferior write to a temporary file on the remote host and then retrieve after the process exits? I don't like this because I think it's really useful to see the debug output from the file during debugging.

Just FYI: if you redirect to a file in a local debug session you won't see any output. We don't monitor the file or do anything with it as you asked for the output to be redirected.

2) Hand the inferior a pipe for each redirected stdout/stderr, transfer the bytes written to the host and then write them on the host to the specified file. What messages do I use for this? It should be independent of $O. I don't want to use the $F messages because they're slightly different (and a lot of

3) ???

For stdin, I think I will just copy to file over to the target and open it on the inferior.

Thoughts?

I would vote to redirect to a file on the remote host and do nothing else. Then you can fetch the file via the platform command:

(lldb) platform get-file ...

I am not sure why, but these are only currently available when LLDB_CONFIGURATION_DEBUG is defined:

#ifdef LLDB_CONFIGURATION_DEBUG
    LoadSubCommand ("mkdir", CommandObjectSP (new CommandObjectPlatformMkDir (interpreter)));
    LoadSubCommand ("file", CommandObjectSP (new CommandObjectPlatformFile (interpreter)));
    LoadSubCommand ("get-file", CommandObjectSP (new CommandObjectPlatformGetFile (interpreter)));
    LoadSubCommand ("get-size", CommandObjectSP (new CommandObjectPlatformGetSize (interpreter)));
    LoadSubCommand ("put-file", CommandObjectSP (new CommandObjectPlatformPutFile (interpreter)));
#endif

Feel free to remote this #if so they are always available.

Currently I have tested the "lang" directory only when doing remote tests:

% ./dotest.py [options] lang

There are many tests that are going to need to be modified for these sorts of things. Such as if we need to redirect stdin from a file, we will need to upload this file first and possibly update the stdin redirect file path to be the new STDIN path on the remote host. Or we can skip these tests for remote for now.

Greg

I would vote to redirect to a file on the remote host and do nothing else. Then you can fetch the file via the platform command:

I’m not super in love with this for a few reasons.

  1. The tests need to be modified and have different behavior for local/remote processes.

  2. Currently, lldb hides a lot of the hassle of running binaries on a remote host by automatically copying them over. This just adds a special case for output.

  3. Conceptually, for the user, this would mean that ‘target create ’ would be a local path but ‘process launch ’ would be a remote path. I would prefer that this always be local path if possible.

I’ve modified a couple of tests to support this. It’s not a big deal but I see a big maintenance problem going forward as people add new tests that work locally but don’t consider the remote case.

Also, I’m hitting a problem with the SBProcess API in TestProcessIO.py. It allows reading/writing bytes at runtime. It’s not sufficient to have the I/O reading/writing from/to files on the remote host. We need to hook up pipes to get this test passing.

Vince

Also, I’m hitting a problem with the SBProcess API in TestProcessIO.py.

Nm on this point, I think this can be done via existing tty mechanism