> On Mar 14, 2016, at 2:08 PM, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Mar 14, 2016, at 1:58 PM, Jim Ingham <jing...@apple.com> wrote: >> >> You can build a dSYM for any linked image. The only thing you can't build >> it for is object and archive files. Whether to do it or not is just a >> tradeoff between build time & preserving debug information long term. > > Thanks … but I’m not getting any insight from that. How about some specific > questions, if I may: > > If I build a static library (.a file) that another developer will link into > their app, do I need to provide a dSYM file too, or does the library already > include all the debug info?
I thought I answered this in my longer reply, but... You could make a .a file of stripped -S .o files, and that would not be debuggable at all. There's no way to use dSYM files to work around that since dsymutil only works on linked images. The linker would still be fine with it, but there isn't a way to give out .a files with no debug information and keep the debug information for after-the-fact symbolication on the distributor's end. So for .a files, you either need to give up debugability, or provide the .a file made of unstripped .o files. In the latter case, you don't need to provide anything else. The person using the .a file can choose to debug using the debug information in the .o file when they link it into a binary image, or they could make a dSYM, either is possible. Note, you also won't be able to symbolicate crashes from a binary that uses a .a file you handed out (even if it had debug information), unless they give you back the dSYM from the binary they linked it into. Otherwise the tools wouldn't know how the symbols in the library got modified in the course of the link. > > What about a framework (with a dylib), again to be used in another > developer’s app? Is there any use for a dSYM file with that? (And if so where > does it go? Inside the .framework somewhere?) You would need to hand out a dSYM as well for them to be able to debug the framework (or for you to symbolicate it after the fact.) The first place lldb looks for .dSYM files is next to the binary image that is loaded by dyld. If there is a dSYM there whose name matches the name of the binary image. Then it looks next to the most proximate containing MacOS X package type (.app, .framework, etc...) In this case, the dSYM name has to match the package name. So you can either do: Foo.framework/Versions/A/Foo.dSYM next to: Foo.framework/Versions/A/Foo or Foo.framework.dSYM next to: Foo.framework Note, lldb uses the binary's UUID to match it to the dSYM, so you don't have to worry about the tools using the wrong dSYM. > > I think I’m generally unclear about what uses dSYM files. Just LLDB? And how > does it find them? Pretty much all the tools that symbolicate binaries on OS X will use dSYM's if they are available. This link describes how dSYM's are handled on OS X: http://lldb.llvm.org/symbols.html This search mechanism is implemented by the DebugSymbols framework, and is shared by all the tools that need to symbolicate. Hope that helps. Jim > > —Jens _______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (Xcode-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com This email sent to arch...@mail-archive.com
