Missing symbol names when profiling IPhone application with Instruments

I am compiling an IPhone application via command line (so no XCode options involved) and I am unable to get my symbol names to show when profiling with Instruments. I have tried several flags such as -gdawrf-2 and -g without any success. I have also tried using dsymutils to generate a .dSYM file but i have no clue how I'm supposed to use it so that failed aswell.

Any help will be greatly appreciated!

I Changed my project settings to not include the dSYM file while building:

Changing it to include the dSYM File helped the profiler desymbolize the symbols and fixed my issue:

I was still having issues with this.

My issue was I was able to see the dSYM file being generated, but Instruments wasn't picking it up.

To fix this, do the following:

1. Locate your dSYM file (should be in ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_TYPE]-[DEVICE-TYPE]/
2. With Instruments stopped, click on File -> Re-Symbolicate Document
3. Scroll down to the entry with your app name
4. Click "Locate" and choose the folder from step 1
5. Click the Start button to begin profiling

How Instruments obtains debug information:

Instruments obtains debug info from a .dSYM file which is normally generated automatically by XCode when setting Debug Information Format to DWARF with dSYM File combined with a checkmark in the Generate Debug Symbols option box. Setting these options will add an extra step to the XCode build process and generate a dSYM file after the application has been compiled. Every dSYM is built with a UUID that corresponds to a UUID in a Mach-O section in the binary that it's derived from. A Spotlight importer indexes the UUIDs of every dSym file that is in a Spotlight-accessible location on your Mac. Therefore SPOTLIGHT does all the black magic and is responsible of making the link between the .app you are running and its corresponding .dSYM file.

How to generate debug information and dSYM file without XCode:

Make sure you are compilig with –gdwarf-2 and -g flags. (Other flag combinations might work)

> -g > Produce debugging information in > the operating system's native format > (stabs, COFF , XCOFF , or DWARF 2). > GDB can work with this debugging > information. On most systems that use > stabs format, -g enables use of extra > debugging information that only GDB > can use; this extra information makes > debugging work better in GDB but will > probably make other debuggers crash or > refuse to read the program. If you > want to control for certain whether to > generate the extra information, use > -gstabs+, -gstabs, -gxcoff+, -gxcoff, or -gvms (see below). GCC allows > you to use -g with -O. The shortcuts > taken by optimized code may > occasionally produce surprising > results: some variables you declared > may not exist at all; flow of control > may briefly move where you did not > expect it; some statements may not be > executed because they compute > constant results or their values were > already at hand; some statements may > execute in different places because > they were moved out of loops.
> Nevertheless it proves possible to > debug optimized output. This makes it > reasonable to use the optimizer for > programs that might have bugs.

> -gdwarf-2 > Produce debugging information in DWARF version 2 format > (if that is supported). This is the > format used by DBX on IRIX 6. With > this option, GCC uses features of > DWARF version 3 when they are useful; > version 3 is upward compatible with > version 2, but may still cause > problems for older debuggers.

Generate a dSYM file using dsymutil. If the tool isn't recognized in command line, use spotlight to find it. IMPORTANT: Place .app file on your mac HD before you generate the dSYM if you are working on a networked drive.

> dsymutil MyApp.app/MyApp -o > MyApp.app.dSYM

Place the .dSYM file on the mac's local drive and run Instruments as you normally would.

Resettig spotlight's indexing:

If symbols aren't shown, it might be because spotligh is bugged. You can try reseting spotlight's indexing by adding your folder containing the dSYM file (or even your drive) to the “Prevent spotlight from searching these locations” in the spotlight preferences and then removing it right away.

In Xcode 4.5 you can choose to Profile from Debug or Release builds. Release defaults to stripping the symbols when copied to the device. It's very easy to switch to the Debug configuration for profiling without breaking your release configuration. To do that, select Product -> Edit Scheme from the XCode menu. Select "Profile" from the list of schemes that comes up, and then select the correct Build Configuration for that.

Or you could make a separate release/profile configuration and use that in your Profile section of your scheme. How to add a separate build configuration is described in the XCode User Guide.

With Xcode 6 Instruments you can provide dSYM file as follow:

• File -> Symbols... menu (when profiling is stopped)
• select your app and press Locate button
• select path which contains dSYM (usually ~/Library/Developer/DerivedData/APP_NAME-XXXXXXX/Build/Products/[BUILD_CONFIGURATION]-[TARGET_PLATFORM]/). Tip: You can copy this path from terminal and use OS X shortcut ⌘+SHIFT+G in dialog.

Also Instruments will ask you if it should use selected path to try load dSYM for this app in the future. Answer Yes :)

Spent three days trying to figure this out for Xcode 7.1/7.3...

Changing the deployment target to the latest version (9.3 at the time) fixed this issue for me. My company targets 7.0 so I will probably have to create a custom Scheme for profiling the code in Instruments to avoid having to change the target (or forgetting to change the target) when we do a production release.

Seems like it's probably a bug if dSYMs fail to work based on the deployment target?

The problem is that spotlight cannot find the .dSYM files. This is because Apple changed the location of the DerivedData folder. The DerivedData now goes in ~/Library

Spotlight will not index ~/Library and as far as I have been able to establish, cannot be made to index it either (e.g. mdimport is ignored).

A work around to get symbols in your profiler, is to simply copy the data outside ~/Library e.g. your home directory will do fine.

I used this command line:

$ cp -r ~/Library/Developer/Xcode/DerivedData/AppName-xxxxxxxxxxx/Build/Products/Release-iphoneos/ ~/

When you kill your profiler, and start a new profile run, you will see that the symbols are available again.

Check the build log and make sure that your -g switch is getting through to the compiler - it's easy to get this wrong when changing settings at the project and/or target levels for different build configurations etc.

Another work around in the version of Instruments that comes with Xcode 4 is to use the Re-Symbolicate Document menu item under the File menu for Instruments. This menu item to allows you to use the symbols located in the .dSYM file in ~/Library/... directory.

In my experience, this is usually because "Profile" has been called before the most recently modified version of the app has been installed on the target device.

Try running the app on the device/target, then calling "Profile" again after it has been reinstalled.

I got this problem because the XCode project was on a network share where Spotlight wouldn't find the dSYM files. Make sure it's on the local drive.