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
On Tue, Jan 27, 2015 at 6:48 PM, Vince Harron <vhar...@google.com> wrote:
> > 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
> <path>' would be a local path but 'process launch <path>' would be a remote
> path. I would prefer that this always be local path if possible.
>
>
>
>
>
> On Fri, Jan 23, 2015 at 5:15 PM, Greg Clayton <gclay...@apple.com> wrote:
>
>>
>> > On Jan 23, 2015, at 12:10 PM, Vince Harron <vhar...@google.com> wrote:
>> >
>> > 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
>>
>>
>>
>>
>
>
> --
>
> Vince Harron | Technical Lead Manager | vhar...@google.com | 858-442-0868
>
--
Vince Harron | Technical Lead Manager | vhar...@google.com | 858-442-0868
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
