[lldb-dev] LLDB for Android initiative

[Todd Fiala]

Ah, got it.  Okay, thanks for explaining!  And having it be two separate
remote processes clearly makes sense given the lldb-platform remote part is
managing the startup of the other, and has all the support needed to push
new code.

There is probably some amount of overlap in lldb-platform and what we
currently do with adb (Android Debug Bridge).  Eventually I'll need to
figure out what makes sense to speed up the compile/deploy/debug/fix cycle.


On Wed, Nov 20, 2013 at 12:58 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> On Nov 19, 2013, at 2:57 PM, Todd Fiala <tfiala at google.com> wrote:
>
> > Thanks for all the pointers and suggestions, Greg!
> >
> > More below.
> >
> > On Tue, Nov 19, 2013 at 1:16 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> > ... stuff deleted...
> > >
> > > 2. Get the LLDB remote solution up and running against a remote Linux
> x86 process.
> > >
> > > Here we get to the first high-level question mark: do we continue to
> use gdbserver, use debugserver, or base something on lldb-platform?  I
> haven't dug into this yet.  I've heard some thoughts on this topic, such as
> (a) LLDB has extended the gdb remote protocol and offers some benefits over
> using gdbserver, (b) debugserver is currently very part-specific and might
> be a painful way to go in the short term (but I haven't heard comments on
> the longer-term potential benefits of toughing through that), and (c)
> lldb-platform is a reasonable starting point and has been used to get some
> traction bringing up LLDB on other chipsets.  Like in (1), I'll want to set
> up a build bot that builds and runs remote tests in this environment.
> > >
> > > Any thoughts on this?
> >
> > For the remote solution I would propose you do the following:
> > - Modify the gdbserver binary to support the extended LLDB packets. All
> these packets are described here:
> >
> > svn cat
> http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt
> >
> >
> > Ok - I'll have a look at that.  Thanks for the link!  How I approach
> this area might depend on the mechanics of getting changes into gdbserver.
> >
> > - Compile the "lldb-platform" binary for x86. This is a binary that can
> get/put files, install executables, make directories and symlinks, list
> remote processes, attach and launch remote processes and much much more. It
> currently uses the GDB remote protocol and all you really need to do is to
> get it to build for linux. After this you can start the lldb-platform
> binary and then attach to it from a remote LLDB. I am currently working on
> a large patch that will be committed in the next few days which exposes the
> platform through the API as lldb::SBPlatform objects.
> >
> > If you get the gdbserver updated to handle the extra packets, this
> should get you debugging in no time on Android. The platform will get you
> the rest of the debugging experience (auto install, remote shell commands,
> and much much more.
> >
> >
> > Sounds promising! I'm not sure I totally understand the interplay of
> lldb-platform and gdbserver in this case --- on the remote debug side, is
> lldb attaching to two processes, an lldb-platform (for the get/put files,
> install executables, etc. platform-type operations) and then also the
> gdbserver (or similar) to do the remote target process control?  Do I have
> that right?  If so - what's the basic idea behind having those be two
> separate pieces?  Thanks!
>
> Yes, one process lldb-platform gets run and attached to. It can spawn a
> new GDB server for each process that it wants to debug. There is a packet
> that says "launch GDB server and hand me back the port number". Then using
> this port and the hostname of the remote platform, you can then attach to
> the remote GDB server and debug as many processes (attach or launch) as
> needed.
>
> This is the biggest part that is missing right now for all many remote
> debugging scenarios: the ability to upload/install the needed files and run
> launch processes on the remote system.
>
> Granted, the current lldb-platform is GDB remote packet based, but we can
> easily switch this to a better technology.
>
> >
> >
> > >
> > > 3. Get the LLDB remote solution up and running against a remote Linux
> ARM system.
> > >
> > > The idea being that it will be easier for me to poke around on the
> Linux ARM system than it would be to go straight for the Android device or
> emulator, but gets me working against an ARM system, one step closer to a
> typical Nexus device.  And helps out ARM Linux remote support in the
> process (if there are any weak spots).  I don't know yet what the scope of
> work here might entail.  Similar to (2), I'll want to set up a build bot
> that builds and runs remote tests in this environment as well.
> >
> > My new upcoming platform patches will allow you to remotely run the test
> suite on there remote devices using the lldb-platform. Everything for ARM
> is the same as the x86 solution above: modify the gdbserver to support the
> LLDB packets and get the lldb-platform to compile for the remote ARM system.
> >
> >
> > I see, okay thanks!
> >
> > >
> > > 4. Getting LLDB remote solution up and running against an Android ARM
> device.
> >
> > Same flow as linux ARM.
> >
> > > 5. Either directly implement or make it straightforward for Android
> vendors to fill in anything necessary to use our remote solution on other
> Android hardware.
> >
> > I think we can grow the SBPlatform and the internal
> lldb_private::Platform to do a lot of great stuff. As soon as my patch
> lands, please take a look and see what you think.
> >
> >
> > Sounds great, thanks.  Looking forward to seeing it, Greg :-)
> >
> > If you have any questions, ask away.
> >
> > Greg Clayton
> >
> >
> >
> >
> > --
> > Todd Fiala |   Software Engineer |     tfiala at google.com |
> 650-397-1352
>
>


-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-397-1352
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131120/f46a5278/attachment.html>