[lldb-dev] LLDB for Android initiative

Wed Dec 4 10:41:51 PST 2013

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
> > >
> > >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131204/6a16523c/attachment.html>