[lldb-dev] LLDB for Android initiative

Greg Clayton gclayton at apple.com
Wed Nov 20 15:56:29 PST 2013


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





More information about the lldb-dev mailing list