[lldb-dev] SBTarget::Launch return SBProcess with PID=0

Tue Apr 1 13:23:04 PDT 2014

On Tue, Apr 1, 2014 at 11:06 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> On Apr 1, 2014, at 12:34 PM, Eran Ifrah <eran.ifrah at gmail.com> 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, at loader_path/../../Library/PrivateFrameworks/
> -Wl,-rpath, at loader_path/../../../SharedFrameworks
> -Wl,-rpath, at loader_path/../../System/Library/PrivateFrameworks
> -Wl,-rpath, at 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 <gclayton at apple.com> 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 <eran.ifrah at gmail.com> 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
> > > lldb-dev at cs.uiuc.edu
> > > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140401/8599cd69/attachment.html>