Hey Greg, 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.
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: * install a remote platform into the Target as part of gdb-remote's command handling. * 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. * 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. 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). Thoughts? Thanks! -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
