XCode supports those 2 values for this Build Setting:
Build Settings > Build Options > Debug Information Format.
Could anybody explain the differences?
The difference is that in the case of DWARF with dSYM file your Archive app.xcarchive (for adHoc distribution) contains also dSYM file needed for reverse symbolication of your code in crash reports. In general, .xcarchive contains
dSyms
Products
info.plist
So if you need it for external analysis of crash reports under archiving you app for distribution you should use DWARF with dSYM file.
As always understanding the abbreviations help!
DWARF is a widely used, standardized debugging data format:
DWARF was originally designed along with Executable and Linkable Format (ELF), although it is independent of object file formats. The name is a medieval fantasy complement to "ELF" that has no official meaning. Only that both (dwarf and elf) are mythological creatures
Debug Symbol (dSYM):
By default, debug builds of an application store the debug symbols inside the compiled binary while release builds of an application store the debug symbols in a companion dSYM file to reduce the binary size.
The Debug Symbol file and application binary are tied together on a per-build-basis by the build UUID. A new UUID is generated for each build of your application and uniquely identifies that build. Even if a functionally-identical executable is rebuilt from the same source code, with the same compiler settings, it will have a different build UUID.
For example, if you have a library libfoo.dylib, the debug symbol file
would be libfoo.dylib.dSYM.
From here
So long story short
DWARF is just a debug file
DWARF with dSYM File is a debug file along with symbolification file
DWARF is embedded in the object files of the binary, but not in the binary itself (unlike stabs, which are linked into the binary proper). dsym extracts the DWARF info from the object files, puts it in a separate dSYM bundle and makes the binary refer to this bundle (instead of to the object files). Docs
Also see DWARF's official home page
Pro tip:
On our project's GitHub repo, on the releases section we have something like this:
We upload the .ipa and dysm file so then if 3 months from now a user has a weird crash for our 10.16 build then we'd go to this release branch and run it with this dsym and try to reproduce the issue.
Both DWARF and DWARF with dSYM create DWARF debug information like on all other platforms, but they differ on where the debug information will be accessed when debugging or symbolicating:
DWARF means that the debug information is left in .o files and this debug information is not linked during the build process. Each .o file will contain unlinked DWARF and the debugger (LLDB, GDB) will link the debug information on the fly when debugging. The main executable contains a debug map contained in the symbol table which has everything that is needed to link the debug information. The maps contains STABS symbol entries that points to each .o file and tells the debugger or linker where everything needs to be linked (for functions, globals and static variables). The debug information will be less efficient since it is not linked, and each .o file can contain type definitions that are also found in other .o files, so the overall debug information size will be bigger. This is often most useful for the edit/compile/debug cycles for when you're implementing new features or trying to track down bugs. The benefit is you do not have to link the debug information during your build process. Not all tools that parse debug information support this mode of debug information, so you might want create dSYM files if local crash reports on your system do not contain source file and line information in the backtraces. Tools like sample, ReportCrash, and Instruments that need to parse debug information might not support the DWARF setting.
DWARF with dSYM means that after you build your executable, a dSYM debug information file will be linked using a tool named dsymutil. dsymutil gets ran after your executable is linked to parse the debug map in the main executable and produce a dSYM file with all of the debug information. Linking the debug information can add to your build times if you have a lot of code in your project. The DWARF debug information in all of the .o files is intelligently linked into the dSYM file. Any code that was dead stripped will have its debug information removed, and the dsymutil will dedup types within the debug information, so the resulting DWARF is much smaller and more efficient. Use this setting when building your releases or if you have a build machine that is caching builds for others to download.
In order to find the dSYM file for an executable, the UUID from the main executable is copied into the dSYM file. A previous comment suggested that the UUID changes with each build even if the same source code and compiler was used, but this is not true. The UUID is a MD5 checksum of the parts of the binary that do not change due to debug information. Debug information can contain paths and other data that change depending on what directory the sources exist in. If the UUID was simply a MD5 checksum of the entire binary, then the UUID would be different for the same sources built with the same compiler if one was built in /tmp/myproj vs /users/data/myproj. So the UUID built into Darwin binaries will match if the important bits (__TEXT, __DATA, etc) are the same even if the project is built in different directories. This allows the UUID to be used to unique dSYM files across multiple builds that produce the same binary. If SDK header files or different compilers or linkers are used, the UUID can easily differ.
There is Spotlight importer for dSYM files knows how to extract the UUID from the dSYM file to make it possible for debuggers and other tools like sample, Instruments, ReportCrash and more to find the dSYM file for a binary even if the dSYM file is not right next to the binary. You can see the UUID of your binary by running dwarfdump:
$ dwarfdump --uuid ~/a.out
UUID: E76A2647-AFB4-3950-943A-CB1D701B7C07 (x86_64) ~/a.out
Then you can use the Spotlight window in your system to search for the dSYM file. There is also a command line tool for spotlight called "mdfind" that can be used:
$ mdfind E76A2647-AFB4-3950-943A-CB1D701B7C07
/Users/admin/a.out.dSYM
So to sum up: use DWARF for edit/compile/debug cycles if you have large projects and want to avoid the time it takes to link a dSYM file during your daily workflow. Use DWARF with dSYM all the time if you have smaller projects, doing release builds, or need other Apple tools that are not debuggers to be able to parse your debug information. Both formats contain the same kind of information and can be used for debugging, but not all tools can load the DWARF format where the DWARF is left in the .o files.
DWARF (debugging with attributed record formats) is a debugging file format used by many compilers and debuggers to support source-level debugging. It is the format of debugging information within an object file. The DWARF description of a program is a tree structure where each node can have children or siblings. The nodes might represent types, variables, or functions.
source: https://www.ibm.com/developerworks/aix/library/au-dwarf-debug-format/index.html
DWARF with dSYM File stores the debug symbols for your app
Services like crashlytics use it to replace the symbols in the crash logs with the appropriate methods names so it will be readable and will make sense.
source : What's the dSYM and how to use it? (iOS SDK)
From "Project Editor Help":
Debug Information Format (DEBUG_INFORMATION_FORMAT)
The type of debug information to produce.
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). dwarf-with-dsym
Related
I've IPA which is uploaded on AppStore. On unzipping IPA I see two folders
Payload and Symbols.
Symbols folder contains many files with extension .symbol
Any idea what would be these symbol files? Can we use them for symbolication?
Yes, it is debug symbols. They contain a mapping between encoded names and locations in your compiled code and the original function names among other debug information. Each <UUID>.symbols file represents either the main binary of you app or a framework that your app is using. You can find out which is which using mdfind (see example).
See this about symbolication
When unzipping the ".ipa" file, the output is: Payload directory that contains the application. However, sometimes the output is: Payload, SwiftSupport and Symbols directories.
What are the conditions to generate both SwiftSupport and Symbols directories?
Also, I noticed that SwiftSupport contains .dylib files, which -I assume- they are already exist in the application (right click -> show package contents -> frameworks), so:
The application should work fine even if they are not exist, what are the purpose of generating them?
I couldn't find any useful reference to describe what I'm looking for.
After playing with archiver I found answers for all your questions.
What are the conditions to generate both SwiftSupport and Symbols directories?
SwiftSupport folder is managed by option ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES from target's Build Settings
Symbols directory is managed by checkbox on export dialog:
Since Xcode 7 there is also support for exportOptionsPlist with symbol export option for command line build, more details here
Second part is more interesting:
The application should work fine even if they are not exist, what are the purpose of generating them?
Answer to this question I found in ... apple's documentation:
Always embed the Swift standard libraries in the target's products, even if the target does not contain any Swift code. For example, this should be enabled if the target is embedding other products which contain Swift, or if it is a test target which does not contain Swift but which is testing a product which does. This setting only applies to wrapped products, not to standalone binary products.
So application's .ipa can contains this folder with libraries even without using of swift directly
As sage444's answer give your some explanation to your answer. There are few points that I have observed.
Symbols: You need this folder to symbolicate your crash logs.
SwiftSupport: Although you have two copies of dylib one in Payload and other in framework. But when you upload it to iTunesConnect then the size of your downloadable app is less than the size of your ipa file. The iTunesConnect manages your duplicate items (dylibs).
For more info you can check this answer
I'm working on an app with another developer and they just submitted a release to the app store that was built on their computer. In order to make a build on my machine (that belongs to the same git commit), I have to alter the path to one of the libraries we use in my XCode project. Will any changes I make to the XCode project file change the dSYM? If I was able to make a build without modifying the XCode project file, would the dSYM file be the same?
A dSYM file is a "debug symbols file". It is generated when the "Strip Debug Symbols" setting is enabled in the build settings of your project.
When this setting is enabled, symbol names of your objects are removed from the resulting compiled binary (one of the many countermeasures to try and prevent would be hackers/crackers from reverse engineering your code, amongst other optimisations for binary size, etc.).
dSYM files will likely change each time your app is compiled (probably every single time due to date stamping), and have nothing to do with the project settings.
They are useful for re-symbolicating your crash reports. With a stripped binary, you won't be able to read any crash reports without first re-symbolicating them. Without the dSYM the crash report will just show memory addresses of objects and methods. Xcode uses the dSYM to put the symbols back into the crash report and allow you to read it properly.
Ideally, your dSYM file shouldn't be tracked in your git repo. Like other binaries that change on building, it's not useful to keep them in source control. However, having that said, it is important that you keep the dSYM files for each distributed build (betas, press releases, app store distributions, etc.) somewhere safe so that you are able to symbolicate any crash reports you might get. Xcode does this automatically for you when you use the Archive option. The created archive contains your app and its dSYM and is stored within Xcode's derived data directory.
I have an iOS project. In response to Build (with a release configuration selected in the scheme) the dsym for it weighs in at 6.5MB. However, when I Archive (with the same configuration selected in the scheme) it weighs in at only 2.9MB.
This is not an academic problem. The missing data includes all the symbols for my static libraries, which is making my crash logs a lot less useful.
Which settings could account for a difference between a Build and Archive with the same configuration selected?
This is with Xcode 5.0, though I think I've been having this problem for a while.
I believe a few things it does are:
Remove all debugging symbols from the app to the .dsym file
Compresses various articles from ascii to binary (such as strings
files)
Some of the differences may be from the following build flags:
DEPLOYMENT_POSTPROCESSING=YES
STRIP_INSTALLED_PRODUCT=YES
SEPARATE_STRIP=YES
COPY_PHASE_STRIP=YES
I am stripping symbols in Xcode 4.5, but realised that if we strip them we cannot symbolicate crash reports. So I am trying to create a copy of the unstripped binary before stripping. It seems this isn't possible with the normal xcode symbol stripping settings, so I've tried digging into run scripts. The problems I have there is
a) It seems the run script runs after code signing, so the app fails to run.
b) I can't find a way to run a run script under distribution/release only.
Any suggestions?
You can symbolicate crash reports when the binary is stripped! Stripping the binaries makes them 30-50% smaller. Symbolicating with unstripped binaries would not give you line numbers after symbolication anyway.
During the build process you also get a dSYM package which is then used instead to symbolicate your crash reports including getting line numbers in them!
In addition, whenever you do a new build, you get a new unique pair of app binary and dSYM package, so you should use archive instead of build when you are releasing a beta or production version.