> 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
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
