Hi, I'd like to know if you have made some progress on the new debug server and the native layer implementation and if you can share it.
On my side, I have a simple NativeProcess plugin and a fully working Mach implementation of the NativeProtocol. My current implementation passes almost all lldb tests. I had to tweak the Native Protocol and some other layer a little to make it works. I would be interested to known what issue you encounter while working on the linux implementation, and if my Mach implementation fit in your work. My work can be found at https://github.com/Jean-Daniel/lldb/tree/native in the native branch Note that as I consider it as an experimentation sandbox, I often rebase the whole patch set to keep the tree clean and don't bother with branch and merge (and obviously breaks the history, but as I'm no only follower until now, this has never been an issue). Thanks Jean-Daniel Le 4 déc. 2013 à 19:41, Todd Fiala <[email protected]> a écrit : > 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 <[email protected]> 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 <[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 -- Jean-Daniel
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
