If you can get the ObjectFileELF to properly set the triple to something that isn't compatible with the host platform, then the platform will be selected automagically when you do: "file a.out". But that won't work for an ELF file that _is_ compatible with the current host (like an "x86_64-*-linux"), so it is probably best to always explicitly specify your platform.
Greg > On Sep 18, 2014, at 10:02 AM, Todd Fiala <tfi...@google.com> wrote: > > Ok that seems reasonable. I'll make sure that path works. > > > On Thu, Sep 18, 2014 at 10:00 AM, Greg Clayton <gclay...@apple.com> wrote: > > > On Sep 18, 2014, at 8:41 AM, Todd Fiala <tfi...@google.com> wrote: > > > > 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? > > We currently do all local debugging here, so I would not want "remote-macosx" > selected as the platform. > > The idea really should be: > > (lldb) platform select remote-linux > (lldb) file ... > (lldb) gdb-remote ... > > > This selects the right platform first and then all other "file ..." and > "gdb-remote ..." will do the right thing for that instance of LLDB. There > doesn't seem to be any other reliable way to do this because even if we try > to look at the host that the gdb-remote wants to use (gdb-remote 1111 uses > localhost, and gdb-remote foo.bar.baz:1111 uses foo.bar.baz) we aren't going > to be able to tell what kind of host it is from the IP address. > > Greg > > > > > -- > Todd Fiala | Software Engineer | tfi...@google.com | 650-943-3180 > _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
