[lldb-dev] LLDB for Android initiative

Tue Feb 4 22:16:12 PST 2014

Hi Paul,

In the short term, we're working on getting top of tree lldb working with
the stock gdbserver.  Steve Pucci is focused on that effort.  There are
quite a few holes in the existing lldb support for stock linux gdbservers
when they are dealing with shared libraries, and Android native code is all
shared libraries (and looks like Linux).  We're hoping to get this working
soon and might be one way to go to work with lldb and Android in the
shorter term.  Steve is starting with the ARM architecture and then likely
will move on to the others.

I'm working on implementing something we're calling lldb-gdbserver (or llgs
for short).  It's what we'll roll debugserver into as soon as it's working
reasonably well for linux.  The top of tree build only builds it for linux
x86_64 right now.  I'll be putting some effort into it over the next few
weeks and hope to get it up and running in some basic fashion relatively
quickly.  llgs, like debugserver, will implement all of the lldb extensions
that increase the throughput of the gdb remote protocol.  This will take
longer to get this all going than the part Steve is working on.  To get it
working across x86_64, x86, ARM and MIPS Android is likely going to take
some time.

That's where lldb sits now with respect to Android.  If you were to use
gdb, you could run with that right now.  I think if you go that route,
you're likely to use the gdb/mi interface to drive a local gdb talking to
the android gdbserver.  You'll end up needing to do something like ndk-gdb,
ndk-gdb.py or the like to set up the connection.  If you abstract that, you
could start with that, confident that you can get it started now.  You can
check out the Eclipse plugins that Android has in AOSP (both the SDK and
NDK plugins) to get an idea what looks like.  The GDB part is just built on
the CDT plugin.

If we were a little further along, we would have an lldb-platform for
android that would run on the host side (rather than the remote side where
it typically runs I think).  That would wrap all the adb setup for port
forwarding and whatnot needed to set up the debug connection to the device.
 But that's a ways off, as I won't bother doing that until we have
gdbserver and llgs working.

The one bit that we'll be putting effort into in lldb for Android remotes
is having the stack backtraces be able understand transitions between
native and java code.  That'll be a big diff vs. current gdb support.  For
an IDE environment like XCode or VS, this might be less interesting since
theoretically you could meld them with a java jdb connection and gdb in the
IDE (see NVidia's VS-based tools, I think they do this).  But being able to
do this at the native debugger level is going to be very helpful for
several scenarios.

So, I'd probably sum it up as: if you need to move fast and quick, we're
not ready yet.  But if you want to know where we're investing long term,
lldb is where we're putting energy.  It probably would be worth trying to
abstract it to some level if you go with gdb.  With lldb you'll end up have
the c++ and python APIs you can use, which can be a nicer way to integrate
than text over your alternative.

Hope that helps :-)

Sincerely,
Todd Fiala

On Tue, Feb 4, 2014 at 6:58 PM, Paul Beusterien <paulb at apportable.com>wrote:

> Any updates on the Android lldb initiative?
>
> We're prototyping Apportable Android NDK development in Xcode and
> investigating whether to integrate lldb or gdb for debugging. Any
> recommendations?
>
> Thanks,
> Paul Beusterien
>
>
> On Tue, Jan 7, 2014 at 8:49 AM, Todd Fiala <tfiala at google.com> wrote:
>
>> Hi Jean-Daniel,
>>
>> Currently I've had to switch gears a bit and address some holes in our
>> testing on the Android side so that we can verify that the gdb remote pipe
>> remains functional between the host and device.  This has kept me busy for
>> the last couple weeks + holiday.  Thus I do not have anything to share at
>> the moment.  It's the top item on my list after that.
>>
>> I'll be sure to have a look at your work when I get there.  Thanks for
>> checking on it!
>>
>> Sincerely,
>> Todd Fiala
>>
>>
>> On Tue, Jan 7, 2014 at 8:07 AM, Jean-Daniel Dupas <devlists at shadowlab.org
>> > wrote:
>>
>>> Hi,
>>>
>>> I'd like to know if you have made some progress on the new debug server
>>> and the native layer implementation and if you can share it.
>>>
>>> On my side, I have a simple NativeProcess plugin and a fully working
>>> Mach implementation of the NativeProtocol.
>>> My current implementation passes almost all lldb tests.
>>>
>>> I had to tweak the Native Protocol and some other layer a little to make
>>> it works.
>>> I would be interested to known what issue you encounter while working on
>>> the linux implementation, and if my Mach implementation fit in your work.
>>>
>>> My work can be found at https://github.com/Jean-Daniel/lldb/tree/nativein the native branch
>>>
>>> Note that as I consider it as an experimentation sandbox, I often rebase
>>> the whole patch set to keep the tree clean and don't bother with branch and
>>> merge (and obviously breaks the history, but as I'm no only follower until
>>> now, this has never been an issue).
>>>
>>> Thanks
>>> Jean-Daniel
>>>
>>> Le 4 déc. 2013 à 19:41, Todd Fiala <tfiala at google.com> a écrit :
>>>
>>> Great, thanks.
>>>
>>> Ed, I'll coordinate with you on git sharing as code develops.
>>>
>>>
>>> On Wed, Dec 4, 2013 at 10:36 AM, Greg Clayton <gclayton at apple.com>wrote:
>>>
>>>> Yes working in trunk should be fine because no one is using this
>>>> feature yet and it shouldn't affect anyone's current work flows.
>>>>
>>>> Greg
>>>>
>>>> On Dec 4, 2013, at 8:56 AM, Todd Fiala <tfiala at google.com> wrote:
>>>>
>>>> > Going back through the initial proposal here:
>>>> >
>>>> > http://www.mail-archive.com/lldb-dev@cs.uiuc.edu/msg02164.html
>>>> >
>>>> > I see the proposal was to do this work in trunk:
>>>> >
>>>> > > Since the new classes can be implemented without impacting the
>>>> current functionality, we propose doing this work in trunk.  Note that
>>>> Greg's platform branch was recently merged.
>>>> >
>>>> > Assuming that is still valid, I could just work in trunk it seems.
>>>>  Sound reasonable?
>>>> >
>>>> > -Todd
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Dec 4, 2013 at 8:40 AM, Todd Fiala <tfiala at google.com> wrote:
>>>> > I'm going to start working on getting lldb-gdbserver working under
>>>> Linux x86_64.
>>>> >
>>>> > What's going to be the right submission workflow for this?  Should I
>>>> plan on working in a separate branch until I have something working, and
>>>> then put up a large patch?  I'll be working in git locally.  If we have
>>>> interim work at check points (but not generally useful yet), does lldb use
>>>> some kind of svn branching where it might make sense to do checkpoint
>>>> check-ins?  That would allow sharing progress outside of my local group
>>>> here.
>>>> >
>>>> > Thanks!
>>>> >
>>>> >
>>>> > On Thu, Nov 21, 2013 at 10:49 AM, Greg Clayton <gclayton at apple.com>
>>>> wrote:
>>>> > Todd,
>>>> >
>>>> > I went ahead and created a new "lldb-gdbserver" tool in
>>>> "trunk/tools/lldb-gdbserver" in the repository.
>>>> >
>>>> > I also started the Host layer abstraction (see include/Host/Debug.h)
>>>> for processes (NativeProcessProtocol) and threads (NativeThreadProtocol).
>>>> >
>>>> > In order to get a lldb-gdbserver up and running, it will be a matter
>>>> of adding new packet support to the GDBRemoteCommunicationServer class to
>>>> accept all of the standard GDB remote packets used for debugging. The
>>>> GDBRemoteCommunicationServer class currently supports the lldb-platform
>>>> packets, but doesn't implement a lot of the normal GDB remote packets.
>>>> >
>>>> > So the work flow to get this working on linux will be:
>>>> > 1 - Implement a linux version NativeProcessProtocol and
>>>> NativeThreadProtocol by having them used the ProcessMonitor stuff that is
>>>> down in the linux native debugger plug-in.
>>>> > 2 - Implement any needed GDB remote packets in
>>>> GDBRemoteCommunicationServer and back them by a single instance of
>>>> NativeProcessProtocol when launching or attaching to a process.
>>>> >
>>>> > If you need any help let me know. I am sure there is stuff missing
>>>> from NativeProcessProtocol and NativeThreadProtocol, so let me know if you
>>>> need anything else. Also please ask questions as you go if you need any
>>>> help.
>>>> >
>>>> > Greg Clayton
>>>> >
>>>> >
>>>> > On Nov 20, 2013, at 4:15 PM, Todd Fiala <tfiala at google.com> wrote:
>>>> >
>>>> > > Perfect, thanks!
>>>> > >
>>>> > > Technically I'll be using whatever the Android NDK gdbserver is -
>>>> I'll need to track down what (if any) patches are applied to that.
>>>> > >
>>>> > >
>>>> > > On Wed, Nov 20, 2013 at 3:56 PM, Greg Clayton <gclayton at apple.com>
>>>> wrote:
>>>> > > If you are going to use a stock gdbserver binary, you will need to
>>>> make a target definition python file. We have a few examples checked in:
>>>> > >
>>>> > > svn cat
>>>> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py
>>>> > > svn cat
>>>> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py
>>>> > >
>>>> > > When debugging using GDB, you will first need to see the exact
>>>> registers that the gdbserver supplies:
>>>> > >
>>>> > > (gdb) maint print raw-registers
>>>> > >
>>>> > > Then you will need to make a register definition file based off of
>>>> that and point lldb to use it:
>>>> > >
>>>> > > (lldb) settings set
>>>> plugin.process.gdb-remote.target-definition-file
>>>> /path/to/trunk/examples/python/x86_64_target_definition.py
>>>> > >
>>>> > > Then LLDB will be able to debug to a remote gdb server that doesn't
>>>> support any of the dynamic register definition packets.
>>>> > >
>>>> > > Greg
>>>> > >
>>>> > >
>>>> > > On Nov 20, 2013, at 2:50 PM, Todd Fiala <tfiala at google.com> wrote:
>>>> > >
>>>> > > > Great, thanks Andy.  Right now I'm just at the point of using the
>>>> stock adb/gdbserver and see what that looks like.  I'll definitely be
>>>> looking at your patch in a bit here :-)
>>>> > > >
>>>> > > >
>>>> > > > On Wed, Nov 20, 2013 at 2:39 PM, Kaylor, Andrew <
>>>> andrew.kaylor at intel.com> wrote:
>>>> > > > Take a look at the patch I sent you.  It uses an lldb platform
>>>> based on ADB to set up the port forwarding and possibly copy files then
>>>> connects to gdbserver.  The implementation is rough, but the basic idea
>>>> seemed to work pretty well.  I was using it to copy over and launch a new
>>>> version of gdbserver because the one that came with the x86 emulator at the
>>>> time didn’t work.
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > -Andy
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > From: lldb-dev-bounces at cs.uiuc.edu [mailto:
>>>> lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Todd Fiala
>>>> > > > Sent: Wednesday, November 20, 2013 2:19 PM
>>>> > > > To: Greg Clayton
>>>> > > > Cc: lldb-dev
>>>> > > > Subject: Re: [lldb-dev] LLDB for Android initiative
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > >
>>>> > > > > 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?
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > ADB runs on the host/local side, and it knows how to forward
>>>> ports to devices (typically over USB).  So, we talk to the local ADB port
>>>> that then forwards communication to the actual device.  I'll need to have a
>>>> look at the guts of it - it might make sense to only use it as a port
>>>> forwarder and go with an lldb-platform on the device side and just stick
>>>> with that.  I'll have a deeper look at that once I get Android gdbserver
>>>> (or equivalent) working.
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > _______________________________________________
>>>> > > > lldb-dev mailing list
>>>> > > > lldb-dev at cs.uiuc.edu
>>>> > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>> >
>>>>
>>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>>>  -- Jean-Daniel
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>>  Todd Fiala | Software Engineer |  tfiala at google.com |  650-943-3180
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>

-- 
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/20140204/6b799e1a/attachment.html>