> so it is probably best to always explicitly specify your platform. Yeah that's fine. I'll be sure to get some kind of documentation around this once I work out the path.
Thanks! -Todd On Thu, Sep 18, 2014 at 10:19 AM, Greg Clayton <gclay...@apple.com> wrote: > 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 > > > > -- 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
