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

[Vince Harron]

> 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
On Jan 28, 2015 5:59 PM, "Vince Harron" <vharron at google.com> wrote:

> 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/17a8b3b5/attachment.html>