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.
Going back through the initial proposal here:
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?
My view: I'd much rather things were done in trunk as per proposal. Makes progress more visible, any issues caught earlier and I think contributions easier done.
I would like to see parts appear in trunk as they become available; it
should make it easier for me to keep the FreeBSD port up to date. If
you make work in progress available via git though I'll test it on
FreeBSD prior to arriving in trunk, and help address any issues prior
to the FreeBSD buildbot complaining.
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.
Ed, I’ll coordinate with you on git sharing as code develops.
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).
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!
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?
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
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, but it looks that’s the best near-term route.
The bullk of our communication is in the lldb-dev mailing list, so feel free to keep your ear to it to hear about updates. Currently all our work is going into top of tree as well, so it’ll all be there until something prevents that from working.