I've just built lldb and lldb-mi from the trunk sources on MacOS and faced these issues:
1). lldb was unable to run target (error: process launch failed: unable to locate debugserver)
2). lldb-mi was unable to run target too (Command 'exec-run'. Invalid process during debug session)
I have this big comment in my code that will help you:
// On OSX, debugserver executable must exists otherwise lldb will not work properly
// we ensure that it exists by checking the environment variable LLDB_DEBUGSERVER_PATH
In other words: set the environment variable LLDB_DEBUGSERVER_PATH to point to debugserver executable (you should have it installed with your XCode)
If you want to run on MacOSX, I would highly recommend just building with Xcode. Why?
1 - It will build a LLDB.framework that contains everything you need including the debugserver, header files, the lldb shared library, lldb python modules, additional python modules, etc. Everything you need in order to link against it, and run against it. On other platforms like linux you run into the "lets scatter files all over the system and hope everyone picks and uses the right stuff. Headers in /usr/local/include/lldb, debugserver goes where? python module lives where? Think of frameworks as directories that contain everything you need. The best thing is you can have multiple LLDB.framework bundles all over and link against any one of them. You won't overwrite the previous header from from build a with build b's header files by copying the headers over the old /usr/local/include/lldb...
2 - If you have setup the lldb_codesign code signature, it will sign things for you correctly
To build the Xcode stuff from the command line just go to the root directory and type:
% xcodebuild -configuration Debug
When it is done, there will be a "build/Debug" folder with everything you need. The make and cmake builds make a bunch of normal unix style binaries (lldb.so, lldb) and have no place to put the resources (like debugserver, python module, etc). With the LLDB.framework, it can locate the LLDB.framework/LLDB binary and find the debugserver relative to itself within the LLDB.framework. Likewise with other tools and python stuff.
And once you get things build, run the "lldb" binary against /bin/ls:
% ./lldb /bin/ls
(lldb) run
Make sure you see some output. This lets you know that debugserver was able to be found and that the code signing worked. If you tried code signing and it failed previously, you need to delete the old debugserver binary and re-create it as the kernel caches the code signature based on the file node (vnode) and even if you later code sign it correctly, it won't update its cache.
I’ve sent you a doc out of band. I used it to day to sync and build llvm/clang/lldb tot
It is derived from the instructions on the lldb website so those should work.
I did have these errors:
(Darwin vharron-macpro3.roam.corp.google.com 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64 i386)
Nuke your lldb/llvm and lldb/llvm-build folder and run xcodebuild again. The Xcode build doesn't always update and build llvm and you have newer LLDB code and old llvm and clang code. By nuking your llvm and llvm-build folder it will cause the xcodebuild to download and rebuild a fresh and up to date clang and allow you to build and link correctly.
# sudo /usr/sbin/DevToolsSecurity --enable
Developer mode is already enabled.
(lldb) r
error: process exited with status -1 (lost connection)
'r' and 'run' are aliases that default to launching through a shell.
Try launching without going through a shell by using 'process launch'.
(lldb) process launch
error: process exited with status -1 (lost connection)
Did you set up the lldb_codesign certificate on your system? v. docs/code-signing.txt . It sounds like your debugserver binary isn't signed with the lldb_codesign cert, or that cert isn't in the necessary keychains.
Look in the Console log to see what debugserver says when it tries to attach. "lost connection" isn't typically what debugserver would say if the problem is a task-for-pid denial (i.e. a code signing problem.) In that case, you usually see something like "could not get task for pid..." lost connection means debugserver has unexpectedly quit for some reason (crashed or exited unexpectedly...) Anyway, if you look in the console log, if it is a code signing problem you will see error messages from debugserver saying it failed to get the task for pid whatever.
Also look in ~/Library/Logs/DiagnosticReports for any crash logs from debugserver.
There was nothing connected to debugserver in ~/Library/Logs/DiagnosticReports.
The only thing I could see was:
(lldb) r
error: process exited with status -1 (lost connection)
'r' and 'run' are aliases that default to launching through a shell.
Try launching without going through a shell by using 'process launch'.
(lldb) process launch
error: process exited with status -1 (lost connection)
If you tell me where to search I'll be glad to provide you with some extra info.
We are going to support the MI functionality and I wonder whether you can tell me which LLVM release will contain lldb-mi?
debugserver may also be exiting unexpectedly. You could try running another copy of lldb, and doing an "attach --wait" for debugserver, then setting a breakpoint on exit, and see why it is exiting.
The MI interface uses LLDB through the SB API interfaces. So it does not need to be built with a specific version of lldb to be used. If you want to use it you should be able to just make it into a dylib, and then include it in whatever app you are making. I don't know what the plans for it in LLVM releases are, however.