On Tue, Apr 1, 2014 at 11:06 PM, Greg Clayton <[email protected]> wrote:
> > On Apr 1, 2014, at 12:34 PM, Eran Ifrah <[email protected]> wrote: > > > Thanks. I decided to debug it and see where it fails. So I built > liblldb.3.5.0.dylib in debug mode and debugged the Launch function... > > > > It turns out that it requires the debugserver and it assumes that it > exists under LLDB.framework/ > > however, I have no such directory within my cmake build :P > > > > Now, "my" debugserver executable terminates immediately after execution: > > > > $debugserver > > killed: 9 > > $ > > Running it under the debugger shows nothing significant (I will try to > dig into this later also...) > > > > However, if set this environment variable ( which I learnt about while > debugging ) within codelite: > > > LLDB_DEBUGSERVER_PATH=/Path/To/CommandLineTools/PrivateFrameworks/LLDB.framework/Resources/debugserver > > > > The process launches successfully and I get a valid process ID (Hooray!) > > > > > > So a question to you guys: > > How do I create a framework out of the build? > > Don't use cmake, use xcodebuild: > > svn co ... > cd lldb > xcodebuild -configuration Release > > I tried building it from the GUI as described by your build.html page (selected the proper schema lldb-tool) and hit build However, it fails during the checkout phase (it is sometimes happens, when svn aborts.. simple svn cleanup & svn up fixes this) > Then in the build results will be in "./build/Release" and all needed > executables will be in "./build/Release/LLDB.framework". The rpath for > things linking against LLDB.framework is set be > "@rpath/LLDB.framework/LLDB". So you will need to modify the LLDB plug-in > that loads LLDB.framework to have a relative path to the LLDB.framework > using linker flags ("Other Linker Flags" in your plug-in build, or > "OTHER_LDFLAGS") > > The process I used is similar to how I distribute codelite: I copy the plugin at the end of the build process into their (LLDBDebugger.dylib + liblldb.3.5.0.dylib) respective location within codelite's bundle ("codelite.app") folder, afterwards I run install_name_tool which makes everything relative to the executable using @executable_path The lldb-tool in the Xcode project builds with multiple rpath linker > settings: > > -Wl,-rpath,@loader_path/../../Library/PrivateFrameworks/ > -Wl,-rpath,@loader_path/../../../SharedFrameworks > -Wl,-rpath,@loader_path/../../System/Library/PrivateFrameworks > -Wl,-rpath,@loader_path/../../Library/PrivateFrameworks > > @loader_path is the location of your codelight LLDB plug-in that needs to > link against LLDB. The path can be relative and I would suggest you put a > copy of LLDB.framework inside your codelight LLDB plugin bundle. > > > > > Is this done manually? (i.e. should I simply create the directory > structure and copy the relevant files to their respective location?) > > No, let Xcode build the framework for you. > > > Sorry for all the noobish questions, its just my OSX knowledge is very > limited compared to Linux/Windows > > But I am working on it ;) > > Just think of frameworks as the dylib + header files + any other files > needed (debugserver, lldb-platform, and more) by the framework. It solves > the issue of having to have multiple directories for includes > (/usr/local/include/lldb), support files (/usr/local/lldb), and for the > dylib (/usr/lib/liblldb.so) and keeps all files together and easily lets > you have more than one LLDB.framework on your system without everyone > having to fight over locations like "/usr/local/include/lldb". > > I thought I achieve this by distributing my application as a bundle (everything is built with rpath and "fixed" using install_name_tool) This is how I distributed codelite for several years now with many OSX happy users ;) > > > > P.S. > > This is how I built LLDB ( I am using the command line and not Xcode for > that purpose) : > > > > - svn checkout llvm > > - cd llvm/tools > > - svn checkout lldb > > - svn checkout clang > > - mkdir build-debug && cd build-debug > > - cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Debug > > - ninja > > > > I also followed the signing process as described here > http://llvm.org/svn/llvm-project/lldb/trunk/docs/code-signing.txt > > On MacOSX, just download LLDB only and let LLDB build the llvm and clang > it requires: > > svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb > cd lldb > xcodebuild -configuration Release > > The build process will automagically download the right LLVM (into > "lldb/llvm") and clang (into "lldb/llvm/tools/clang") and then build llvm > and clang into a LLVM specific build folder ("lldb/llvm-build") for all > required architectures (i386 and x86_64). > > > > > P.P.S > > I really hope that this mailing list is archived somewhere on the web so > someone else who wishes to implement LLDB plugin for <choose the IDE name> > will benefit for my noob questions > > Anything that isn't clear from our "http://lldb.llvm.org/build.html"; page > should be updated. Feel free to suggest any improvements to these > instructions. > > The main problem you will run into is that you won't be able to distribute > your "LLDB.framework" to others as the lldb_codesign is only valid for your > machine. One thing you can do is to download the latest Xcode (5.1) Done from the AppStore and copy the > /Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Resources/debugserver. > It will contain a "debugserver" which is codesigned by Apple and won't run > into the lldb_codesign issues on other MacOSX systems. "debugserver" is the > only thing that requires the special code signing because it does the > debugging and requires special privileges. Thanks, will do this > So you can build the LLDB.framework and detailed above, then copy the > debugserver from the latest Xcode release and place it into your > LLDB.framework. > > Greg > > I now got the plugin to control the process properly (step-in/step-over/step-out/continue/breakpoints management + backtrace) I think that this was the biggest obstacle so far and I am hoping to finish the plugin (or at least to make it usable) by this weekend) - I have a waiting list for people who are anxious to try it out Since its open-source, other people can enjoy having a fully working code to copy/paste from ;) Thanks! > > > > Thanks, > > Eran > > > > > > > > > > On Tue, Apr 1, 2014 at 9:43 PM, Greg Clayton <[email protected]> wrote: > > The easiest way to see what is going on is to enable gdb-remote packet > logging. Make sure you tell Codelight to source the init files when you > create your debugger: > > > > // Init LLDB > > SBDebugger::Initialize(); > > > > // Create debugger > > bool source_init_files = true; > > SBDebugger debugger = SBDebugger::Create(source_init_files); > > > > Then add the following line to your ~/.lldbinit file: > > > > log enable -f /tmp/packets.txt gdb-remote packets > > > > Then run and watch your pid come back with zero. Quit code light and > attach the packets.txt file to a reply email and we can see what is going > on. > > > > Did you follow the code signing instructions? You might want to verify > that your command line LLDB can indeed debug something: > > > > % ./lldb /bin/ls > > (lldb) process launch > > > > > > Make sure it completes successfully. > > > > > > > > On Apr 1, 2014, at 1:19 AM, Eran Ifrah <[email protected]> wrote: > > > > > Hello, > > > > > > I have passed most of the barriers I had in order to integrate lldb > within codeite and I have started testing the code on OSX. > > > I have OSX 10.9 and I compiled lldb (btw, an enforcement in CMake to > ensure that Xcode is installed would be nice) > > > When I start debugging from within codelite using lldb, the call to > m_target.Launch(...) where (m_target is of type SBTarget) returns a valid > SBProcess, i.e. m_target.Launch().IsValid() is true > > > > > > However, calling m_target.GetProcess().GetProcessID() returns 0 > > > Doing "ps -ef|grep TestLLDB" in the Terminal.app shows that the > debuggee process was indeed launched ( I can confirm that the parent > process is codelite) > > > > > > Any ideas why it may return 0? > > > > > > TIA, > > > > > > -- > > > Eran Ifrah > > > Author of codelite, a cross platform open source C/C++ IDE: > http://www.codelite.org > > > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org > > > _______________________________________________ > > > lldb-dev mailing list > > > [email protected] > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > > > -- > > Eran Ifrah > > Author of codelite, a cross platform open source C/C++ IDE: > http://www.codelite.org > > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org > > -- Eran Ifrah Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
