[lldb-dev] gdb-remote command

[Greg Clayton]

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 <tfiala at 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 <gclayton at apple.com> wrote:
> 
> > On Sep 18, 2014, at 8:41 AM, Todd Fiala <tfiala at 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 |	 tfiala at google.com |	 650-943-3180
>