<div dir="ltr">Hey Greg,<div><br></div><div>When we fire off a '(lldb) gdb-remote host:port' command on lldb Linux, some bits don't get set up right.  The issue seems to be that the platform for the gdb-remote target is using what looks like the current default platform, where Platform::IsHost() returns true.  This screws up some process-launching setup, notably pty setup (it tries to use local ptys rather than ignoring that part and going with $O messages).  It might be causing other issues as well that I just haven't seen given that the target platform's IsHost() is returning an incorrect value when attached to a remote system.</div><div><br></div><div>I'm in the process of fixing that up for Linux so I can better address pty setup for local llgs and remote llgs debugging scenarios.  What do you think is the right approach to addressing that?  Some ideas that come to mind:</div><div><br></div><div>* install a remote platform into the Target as part of gdb-remote's command handling.</div><div><br></div><div>* modify gdb-remote to take an option for treating as local or remote.  Do the right thing with PTYs based on that.  Might need to pass extra state around somewhere for that.</div><div><br></div><div>* have the pty check do "something else" to figure out whether the target is really going to run locally.  Not sure where that state would go.  Target::GetPlatform()::IsHost() seems like the right place to deal with that.</div><div><br></div><div>I probably have a couple more questions based on your preference here.  (e.g. if installing a remote-aware Platform instance into the Target, which one?  Wait for gdb-remote to tell us?  The important bit is that IsHost() return true in this case.  But - PlatformLinux will try to do the lldb-platform route which gdb-remote's direct-to-llgs approach is not using.  Also - technically we won't know what the remote side is until we get qHostInfo data back).</div><div><br></div><div>Thoughts?</div><div><br></div><div>Thanks!</div><div><br></div><div>-Todd</div></div>