[lldb-dev] LLDB for Android initiative

Tue Nov 19 13:05:34 PST 2013

Hey, awesome Andy!

Thanks for the patch and the details.  I'm pretty sure I'll be interested
in trying to at least get the current Android gdbserver working with lldb
if for no other reason than to help decouple the remote platform piece from
any other work that could be done in parallel on the lldb side.  I'm sure
this will be useful info (and maybe code too) to have in that pursuit.
 Very much appreciated!

> The register definition mechanism that Matt referred you to is much
better.

I definitely have a task on my list to look at that.  Glad to hear others
have given the idea a once-over, too.

Sincerely,
Todd Fiala

On Tue, Nov 19, 2013 at 12:54 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:

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

-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-397-1352
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131119/54a39a54/attachment.html>