[lldb-dev] LLDB for Android initiative

[Matt Kopec]

Hi Todd,

It's great that you are looking at lldb!

In general, it looks like many of the things you want to do with lldb right
now you can, to some extent. I don't think there are too many people
looking at lldb for Linux right now as the Linux buildbots are failing so
there may be bugs introduced as time goes on. Also, the only real way to do
some remote debugging with Linux today is to use gdbserver. The major
feature lldb for Linux (and useful for lldb in general) would benefit from
is a "lldbserver" that works for all platforms.

I've also provided some comments inlined below...

Thanks,
Matt

On Mon, Nov 18, 2013 at 11:40 PM, Todd Fiala <tfiala at google.com> wrote:

> Hi all!
>
> I'm starting up an effort to get LLDB running on Android.  I just wanted
> to reach out, say hi, and give you an outline of how I'm thinking about
> attacking this effort.  I'm looking for feedback, so please fire away if
> you have any suggestions or comments!
>
>  I'm thinking of attacking the effort in stages, looking something like
> this:
>
> 1. Get LLDB up and running against a local Linux x86 process.
>
>  It looks like many aspects of this already work.  I've heard there might
> be some rough edges around core dump support, DWARF 4/5 support, and
> possibly some optimized debug info support on the clang side, so any work
> here might touch those areas.
>
> I see we have what looks like 2 buildbots dedicated to building lldb in
> linux scenarios:
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang
>  http://lab.llvm.org:8011/builders/lldb-x86_64-linux
>
> Android currently builds linux host tools as 32-bit.  Both of those
> buildbots above appear to be 64-bit. I'd love to get the equivalent of an
> Ubuntu 12.04 LTS x64 buildbot building a 32-bit LLDB executable.  How can I
> go about setting that up?
>
>
> You can provide your own buildbot using the instructions here:
http://llvm.org/docs/HowToAddABuilder.html

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?
>
> > You can use gdbserver with lldb today. Though, there are packets lldb
supports that gdb doesn't. For instance, lldb figures out the remote server
register set through special packets. This works with debugserver
(debugserver is mac/ios only) but not with gdbserver. In the gdbserver
case, I believe lldb will default to some version of ARM registers for the
register set. So, connecting to gdbserver you may need to know the remote
registers beforehand and provide that to lldb (more details here
http://llvm.org/viewvc/llvm-project?view=revision&revision=192646). Other
then this, my understanding is that lldb works reasonably well with
gdbserver. There are other benefits of debugserver over gdbserver today
such as better network/packet performance though I haven't seen the numbers
myself.

There was a proposal made on the mailing list a few months ago with regards
to implementing platform-independent remote debugging. That proposal is
found here: http://www.mail-archive.com/lldb-dev@cs.uiuc.edu/msg02164.html.
It's fairly detailed but in essence the idea was that if debug support was
added for, say, FreeBSD on ARM (in one place), then both native and remote
debugging would work for this platform immediately. So, among other things
suggested in the proposal, a new "lldbserver" which supports the current
packets debugserver does but is platform independent. Overall, this will
require effort and I don't think anyone is working on it. It would be great
to have!


> 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.
>
> If you have a gdbserver built for Linux ARM this might just work. You'll
only be able to poke around on the 'gdb-remote plugin' side of lldb in this
case. This plugin is used independent of what gdbserver or debugserver you
are connecting to and works well.


> 4. Getting LLDB remote solution up and running against an Android ARM
> device.
>
> > Same as above, the gdbserver that comes with the Android NDK should work
(maybe it will even work in the Linux case?).


> 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.
>
> > Only thing I can think of here is supporting new x86_64/ARM/MIPS
registers as they come along.

I look forward to working with the LLDB community on this effort!
>  Suggestions or comments are appreciated.
>
> Sincerely,
> Todd Fiala
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131119/1e5b84e3/attachment.html>