When you build a library, the location of the source files is written into the debug information which is stored in the dSYM. When you are in the debugger and stop in some code from that library, lldb uses the debug info to figure out where you have stopped, and load the source for that location. The debug information tells it the location on the build machine, but there's nothing to tell us where the sources are on the debugging machine. You have to do that by hand.
The way to do that in lldb is to set the "target.source-map" setting. So for instance, if on the builder your project was in /Volumes/Builder/Sources, and on the users machine the sources are in /Volumes/TheirDisk/Sources, you would say: (lldb) settings set target.source-map /Volumes/Builder/Sources /Volumes/TheirDisk/Sources Then lldb will take any source file that claims to be under the original hierarchy, and look for it under the new hierarchy instead. If you don't know the original build directory, just do: (lldb) image lookup -vn <SomeFunctionInTheLibrary> and one of the output lines will be the CompileUnit. That will show the path to the source file that was in the DWARF. This generally isn't at the top level of the build hierarchy, so you'll need to go back a couple of directories. You can generally tell what the common base is from looking at the sources you've downloaded. Jim > On May 13, 2015, at 3:34 PM, Eric Wing <[email protected]> wrote: > > This echoes similar sentiments to the recent thread, "How to > distribute & use a dynamic framework for iOS?". > > I am distributing pre-built libraries for both OS X and iOS (dynamic > .frameworks on OS X and static .a libraries on iOS). The code is open > source, but echoing the sentiments of the other thread, there are lots > of really good reasons to distribute ready-to-go binaries. > > But some times, it is really useful to be able to see into those > libraries in the debugger when debugging a problem. For dynamic > libraries, I know I can build a .dSYM and for static libraries, I can > compile debug symbols directly into the libraries. > > But when actually debugging programs that use these libraries, I can > step into the associated source code on the machine that actually > compiled these libraries. > > I want to allow some body else on a different computer who has > downloaded the source code, to be able to step into routines in the > Xcode debugger and see everything resolve, without them needing to > recompile all the libraries themselves and replacing mine. > > I was hoping just having the Xcode project open on the library project > might make things 'just work', but that didn't work. > > I would really appreciate any insights on how to make this work. > > Thanks, > Eric > -- > Beginning iPhone Games Development > http://playcontrol.net/iphonegamebook/ > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Xcode-users mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/xcode-users/jingham%40apple.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to [email protected]
