[lldb-dev] process launch -o /tmp/foo.out

[Vince Harron]

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 <vharron at 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 <gclayton at apple.com> wrote:
>
>>
>> > On Jan 23, 2015, at 12:10 PM, Vince Harron <vharron at 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 | vharron at google.com | 858-442-0868
>



-- 

Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150128/d4fd731e/attachment.html>