Re: DWARF with or without dSYM?
Re: DWARF with or without dSYM?
- Subject: Re: DWARF with or without dSYM?
- From: Jim Ingham <email@hidden>
- Date: Mon, 14 Mar 2016 13:38:52 -0700
When the compiler builds object files, ti writes (in our case DWARF) debug information into the output. When "ar" builds static archive libraries, the .o files with their debug information intact are copied into the archives. In both cases the debug information is unlinked. So it isn't really useful for debugging yet. Then when ld (ld64) builds a linked image, then it writes a "debug map" in the linked image that points back to the .o file's debug info (either as standalone files or in archives.) But unlike on other systems it does not copy the debug information into the final linked products.
The nice thing about this scheme is that if you rebuild one .o file you don't have to copy or link all the debug information in your project. You emit the debug info in that one .o file, and the linker has to re-generate the debug map, which is pretty quick. Very nice for turnaround time in development. The awkward things about it are that it relies on the exact location of a whole bunch of .o files, and it relies on a map in the executable that contains a lot of information you're going to want to strip for release.
So dSYM's... To build a dSYM, dsymutil reads the link map from a linked image, pulls the DWARF out of all the .o files it points to, copies it into the standalone dSYM file, and uses the debug map to link the dwarf to match the linking of the actual symbols in the image. That way you can strip your image & discard the .o files, and just rely on the dSYM.
By design, the dSYM's are equivalent to .o files + debug map for actual debugging, so you COULD always make dSYM files for any linked image. The only reason not to do this is turnaround time for development. They aren't bigger than the sum of the .o files, in fact they tend to be smaller since dsymutil does some type uniquing on the output. So you aren't losing anything but time in building them.
Note the the way it is currently designed, .o files and archive files are equivalent. Since archive files aren't linked products, dsymutil doesn't handle them. If you want to provide .a files that retain their debug information, you have to hand out the archive with full debug information. It would be possible to make an unlinked dSYM from an archive file, but to use it the consumer of the dSYM would have to get their link map back to the producer, so it wouldn't be terribly convenient. Anyway, there wasn't enough call to warrant adding this complexity.
So for rules... If you plan to delete your build products and still be able to debug, you need to make dSYM's. Otherwise it is optional, but build turnaround time will be faster (sometimes much faster depending on how much debug information you have) if you don't build the dSYM.
Hope this helps...
Jim
> On Mar 14, 2016, at 12:54 PM, Jens Alfke <email@hidden> wrote:
>
> I’m trying to clean up the build settings of a very complex Xcode project. One setting that I’m unsure of is DEBUG_INFORMATION_FORMAT — when should one use plain “DWARF", and when "DWARF with dSYM"?
>
> All I know is what it says in the help pane, but that blurb doesn’t say when to use which:
>
>> DWARF - Object files and linked products will use DWARF as the debug information format. [dwarf]
>> DWARF with dSYM File - Object files and linked products will use DWARF as the debug information format, and Xcode will also produce a dSYM file containing the debug information from the individual object files (except that a dSYM file is not needed and will not be created for static library or object file products).
>
> The project has many targets of many types — apps, static libraries, dynamic libraries, frameworks, test bundles — for multiple platforms. Some of these targets are used internally as dependencies and some are released as end products. The end products are mostly frameworks and static libraries, and it’s important that debugging symbols get preserved so that developers linking our code into their apps can get meaningful crash reports if our code is on the stack.
>
> —Jens
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden