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 <[email protected]> wrote: > Going back through the initial proposal here: > > http://www.mail-archive.com/[email protected]/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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > 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: [email protected] [mailto:[email protected]] > > > 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 > > > [email protected] > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
