[lldb-dev] LLDB for Android initiative

[Kaylor, Andrew]

Hi Todd,

I did some experimental work back in September to see what the road blocks might be in getting LLDB working with Android.  I'm attaching a patch from the branch I was working on back then.  This patch is probably badly out-of-date now, and it only just wiggled even when it was fresh.  It might be of some use to you though.

The patch contains several things of varying degrees of usefulness.

1. It implements LLDB "platform" support based on ADB.  The idea behind this was to see if I could get LLDB to attach to a "clean" Android device and install whatever bits were necessary to connect and start debugging.  This sort of worked but it's quite sloppy, has almost no error handling and it's debatable how much value it provides.  Also, this was my first exploration of LLDB's platform mechanism, which was relatively new at the time, and I can't promise I was doing it right.

2. It provides a set of hard-coded x86-based register definitions.  This is absolutely not the correct way to do this, but it was the quickest way to get something working.  You'd think you could reuse one of the existing register context classes provided by LLDB, but the implementation that was current at the time didn't work that way (and I think it still doesn't).  The register definition mechanism that Matt referred you to is much better.

3. It fixes a problem with LLDB's remote protocol handling that causes it to throw away register values provided in a gdb-remote packet if the values don't appear in the expected order.  The particular problem this fixed for me was that the version of gdbserver I was working with was sending stop packets with values for the stack and instruction pointer registers, but they appeared before the thread info and so LLDB was ignoring them.  This was compounded by the fact that the version of gdbserver I was using wasn't responding to attempts to query the value of these registers directly (or rather it was responding but it wasn't giving me the values).

With this patch, I was able to attach to a process running on an x86 emulator.  As I recall I wasn't able to set a breakpoint. I didn't get as far as figuring out why, but I suspect it was something simple.

I definitely think that the platform independent remote debugging proposal that Matt referred you to is the correct direction for future work, but getting things working with gdbserver is probably at least an interesting exercise.

Good luck!

-Andy



From: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Todd Fiala
Sent: Monday, November 18, 2013 8:41 PM
To: lldb-dev at cs.uiuc.edu
Subject: [lldb-dev] LLDB for Android initiative

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?

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?

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.
[https://mail.google.com/mail/ca/u/0/images/cleardot.gif]
4. Getting LLDB remote solution up and running against an Android ARM device.

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 look forward to working with the LLDB community on this effort!  Suggestions or comments are appreciated.

Sincerely,
Todd Fiala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131119/b8e89012/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: android-lldb.patch
Type: application/octet-stream
Size: 50105 bytes
Desc: android-lldb.patch
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131119/b8e89012/attachment.obj>