[lldb-dev] LLDB for Android initiative

Wed Feb 5 12:10:45 PST 2014

Hi Todd,

Thanks for the detailed response!

 We were hoping not to have to continue down the path of merging the Apple
6.x gdb/mi extensions into our 7.x gdb fork<https://github.com/apportable/gdb>,
but it looks that's the best near-term route.

On Tue, Feb 4, 2014 at 10:16 PM, Todd Fiala <tfiala at google.com> wrote:

> 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/20140205/d2e4b295/attachment.html>