[lldb-dev] gdb-remote command

[Todd Fiala]

> 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 <gclayton at 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 <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
> >
>
>


-- 
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/930cfb68/attachment.html>