[lldb-dev] gdb-remote command

Todd Fiala tfiala at google.com
Thu Sep 18 10:02:31 PDT 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140918/b20574ef/attachment.html>


More information about the lldb-dev mailing list