On Nov 20, 2013, at 1:21 PM, Todd Fiala <[email protected]> wrote: > Ah, got it. Okay, thanks for explaining! And having it be two separate > remote processes clearly makes sense given the lldb-platform remote part is > managing the startup of the other, and has all the support needed to push new > code.
Yep. > > 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? > > On Wed, Nov 20, 2013 at 12:58 PM, Greg Clayton <[email protected]> wrote: > > On Nov 19, 2013, at 2:57 PM, Todd Fiala <[email protected]> wrote: > > > Thanks for all the pointers and suggestions, Greg! > > > > More below. > > > > On Tue, Nov 19, 2013 at 1:16 PM, Greg Clayton <[email protected]> wrote: > > ... stuff deleted... > > > > > > 2. Get the LLDB remote solution up and running against a remote Linux x86 > > > process. > > > > > > Here we get to the first high-level question mark: do we continue to use > > > gdbserver, use debugserver, or base something on lldb-platform? I > > > haven't dug into this yet. I've heard some thoughts on this topic, such > > > as (a) LLDB has extended the gdb remote protocol and offers some benefits > > > over using gdbserver, (b) debugserver is currently very part-specific and > > > might be a painful way to go in the short term (but I haven't heard > > > comments on the longer-term potential benefits of toughing through that), > > > and (c) lldb-platform is a reasonable starting point and has been used to > > > get some traction bringing up LLDB on other chipsets. Like in (1), I'll > > > want to set up a build bot that builds and runs remote tests in this > > > environment. > > > > > > Any thoughts on this? > > > > For the remote solution I would propose you do the following: > > - Modify the gdbserver binary to support the extended LLDB packets. All > > these packets are described here: > > > > svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt > > > > > > Ok - I'll have a look at that. Thanks for the link! How I approach this > > area might depend on the mechanics of getting changes into gdbserver. > > > > - Compile the "lldb-platform" binary for x86. This is a binary that can > > get/put files, install executables, make directories and symlinks, list > > remote processes, attach and launch remote processes and much much more. It > > currently uses the GDB remote protocol and all you really need to do is to > > get it to build for linux. After this you can start the lldb-platform > > binary and then attach to it from a remote LLDB. I am currently working on > > a large patch that will be committed in the next few days which exposes the > > platform through the API as lldb::SBPlatform objects. > > > > If you get the gdbserver updated to handle the extra packets, this should > > get you debugging in no time on Android. The platform will get you the rest > > of the debugging experience (auto install, remote shell commands, and much > > much more. > > > > > > Sounds promising! I'm not sure I totally understand the interplay of > > lldb-platform and gdbserver in this case --- on the remote debug side, is > > lldb attaching to two processes, an lldb-platform (for the get/put files, > > install executables, etc. platform-type operations) and then also the > > gdbserver (or similar) to do the remote target process control? Do I have > > that right? If so - what's the basic idea behind having those be two > > separate pieces? Thanks! > > Yes, one process lldb-platform gets run and attached to. It can spawn a new > GDB server for each process that it wants to debug. There is a packet that > says "launch GDB server and hand me back the port number". Then using this > port and the hostname of the remote platform, you can then attach to the > remote GDB server and debug as many processes (attach or launch) as needed. > > This is the biggest part that is missing right now for all many remote > debugging scenarios: the ability to upload/install the needed files and run > launch processes on the remote system. > > Granted, the current lldb-platform is GDB remote packet based, but we can > easily switch this to a better technology. > > > > > > > > > > > 3. Get the LLDB remote solution up and running against a remote Linux ARM > > > system. > > > > > > The idea being that it will be easier for me to poke around on the Linux > > > ARM system than it would be to go straight for the Android device or > > > emulator, but gets me working against an ARM system, one step closer to a > > > typical Nexus device. And helps out ARM Linux remote support in the > > > process (if there are any weak spots). I don't know yet what the scope > > > of work here might entail. Similar to (2), I'll want to set up a build > > > bot that builds and runs remote tests in this environment as well. > > > > My new upcoming platform patches will allow you to remotely run the test > > suite on there remote devices using the lldb-platform. Everything for ARM > > is the same as the x86 solution above: modify the gdbserver to support the > > LLDB packets and get the lldb-platform to compile for the remote ARM system. > > > > > > I see, okay thanks! > > > > > > > > 4. Getting LLDB remote solution up and running against an Android ARM > > > device. > > > > Same flow as linux ARM. > > > > > 5. Either directly implement or make it straightforward for Android > > > vendors to fill in anything necessary to use our remote solution on other > > > Android hardware. > > > > I think we can grow the SBPlatform and the internal lldb_private::Platform > > to do a lot of great stuff. As soon as my patch lands, please take a look > > and see what you think. > > > > > > Sounds great, thanks. Looking forward to seeing it, Greg :-) > > > > If you have any questions, ask away. > > > > Greg Clayton > > > > > > > > > > -- > > Todd Fiala | Software Engineer | [email protected] | 650-397-1352 > > > > > -- > Todd Fiala | Software Engineer | [email protected] | 650-397-1352 > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
