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

[Vince Harron]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150127/91c3fae1/attachment.html>