Hi Todd,
Thanks for the detailed response! We were hoping not to have to continue down the path of merging the Apple 6.x gdb/mi extensions into our 7.x gdb fork<https://github.com/apportable/gdb>, but it looks that's the best near-term route. On Tue, Feb 4, 2014 at 10:16 PM, Todd Fiala <[email protected]> wrote: > Hi Paul, > > In the short term, we're working on getting top of tree lldb working with > the stock gdbserver. Steve Pucci is focused on that effort. There are > quite a few holes in the existing lldb support for stock linux gdbservers > when they are dealing with shared libraries, and Android native code is all > shared libraries (and looks like Linux). We're hoping to get this working > soon and might be one way to go to work with lldb and Android in the > shorter term. Steve is starting with the ARM architecture and then likely > will move on to the others. > > I'm working on implementing something we're calling lldb-gdbserver (or > llgs for short). It's what we'll roll debugserver into as soon as it's > working reasonably well for linux. The top of tree build only builds it > for linux x86_64 right now. I'll be putting some effort into it over the > next few weeks and hope to get it up and running in some basic fashion > relatively quickly. llgs, like debugserver, will implement all of the lldb > extensions that increase the throughput of the gdb remote protocol. This > will take longer to get this all going than the part Steve is working on. > To get it working across x86_64, x86, ARM and MIPS Android is likely going > to take some time. > > That's where lldb sits now with respect to Android. If you were to use > gdb, you could run with that right now. I think if you go that route, > you're likely to use the gdb/mi interface to drive a local gdb talking to > the android gdbserver. You'll end up needing to do something like ndk-gdb, > ndk-gdb.py or the like to set up the connection. If you abstract that, you > could start with that, confident that you can get it started now. You can > check out the Eclipse plugins that Android has in AOSP (both the SDK and > NDK plugins) to get an idea what looks like. The GDB part is just built on > the CDT plugin. > > If we were a little further along, we would have an lldb-platform for > android that would run on the host side (rather than the remote side where > it typically runs I think). That would wrap all the adb setup for port > forwarding and whatnot needed to set up the debug connection to the device. > But that's a ways off, as I won't bother doing that until we have > gdbserver and llgs working. > > The one bit that we'll be putting effort into in lldb for Android remotes > is having the stack backtraces be able understand transitions between > native and java code. That'll be a big diff vs. current gdb support. For > an IDE environment like XCode or VS, this might be less interesting since > theoretically you could meld them with a java jdb connection and gdb in the > IDE (see NVidia's VS-based tools, I think they do this). But being able to > do this at the native debugger level is going to be very helpful for > several scenarios. > > So, I'd probably sum it up as: if you need to move fast and quick, we're > not ready yet. But if you want to know where we're investing long term, > lldb is where we're putting energy. It probably would be worth trying to > abstract it to some level if you go with gdb. With lldb you'll end up have > the c++ and python APIs you can use, which can be a nicer way to integrate > than text over your alternative. > > Hope that helps :-) > > Sincerely, > Todd Fiala > > > On Tue, Feb 4, 2014 at 6:58 PM, Paul Beusterien <[email protected]>wrote: > >> Any updates on the Android lldb initiative? >> >> We're prototyping Apportable Android NDK development in Xcode and >> investigating whether to integrate lldb or gdb for debugging. Any >> recommendations? >> >> Thanks, >> Paul Beusterien >> >> >> On Tue, Jan 7, 2014 at 8:49 AM, Todd Fiala <[email protected]> wrote: >> >>> Hi Jean-Daniel, >>> >>> Currently I've had to switch gears a bit and address some holes in our >>> testing on the Android side so that we can verify that the gdb remote pipe >>> remains functional between the host and device. This has kept me busy for >>> the last couple weeks + holiday. Thus I do not have anything to share at >>> the moment. It's the top item on my list after that. >>> >>> I'll be sure to have a look at your work when I get there. Thanks for >>> checking on it! >>> >>> Sincerely, >>> Todd Fiala >>> >>> >>> On Tue, Jan 7, 2014 at 8:07 AM, Jean-Daniel Dupas < >>> [email protected]> wrote: >>> >>>> 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/nativein >>>> 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 >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >> > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-943-3180 >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
