[lldb-dev] LLDB for Android initiative

[Greg Clayton]

On Nov 20, 2013, at 1:21 PM, Todd Fiala <tfiala at google.com> wrote:

> 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.

Yep.

> 
> 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.

You can make a new platform named "remote-andriod" that can talk to adb, and just skip using the "lldb-platform" binary. Anything that is missing in that we need in the lldb_private::Platform class could then be added to adb, and if we are missing anything in the lldb_private::Platform compared to adb we could add to the platform API. How do you communicate with adb? Sockets? 

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