http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #16 from Jack Howarth <howarth at nitro dot med.uc.edu> 2010-12-05 20:12:30 UTC --- As a refresher, the original comments from the Apple dsymutil maintainer on the FORM_ref4 were... ------------------------------------------------ The warning was cause for alarm, and the root cause has been fixed (checked in), though it isn't affecting your test case. If you see this type of warning again before you get a fixed dsymutil, look at the dwarfdump output as you were doing for a matching attribute value. In this case it was: 0x00000205: TAG_subrange_type [28] =20 AT_type[FORM_ref4] ( {0x00000048} ( base ) ) AT_upper_bound[FORM_ref4] ( {0x00000149} ) Then you want to make sure that the reference (FORM_ref4) it has ({0x00000149}) made it into the output file which it did: 0x00000149: TAG_variable [21] =20 AT_artificial[FORM_flag] ( 0x01 ) AT_type[FORM_ref4] ( {0x0000020f} ( const base ) ) AT_location[FORM_data4] ( 0x00000144 0x0000000100000d46 - 0x0000000100000e62: r13-1 0x0000000100000e64 - 0x0000000100000e6f: r13-1 ) So everything is ok in this case. dsymutil will track exactly which DIEs make it into the dSYM and only put those DIEs and the dependent DIEs. This helps deal with gcc's one definition rule which can bloat up the debug info. If dead code stripping is on, and only one function of 100 makes it into the dSYM, we strip 99% of the debug info and keep the DWARF small. In a failing case, dsymutil would not add 0x00000149 to the output dSYM and the DWARF would have a DIE with an invalid reference. ------------------------------------------------ So pruning these errors will mask the fact that darwin9 may potentially generate bad DWARF debug information. Alternatively we could drop the pruning and move the expansion of the source types to gcc/config/darwin10.h per Comment 12 if we always want to have pristine DWARF generated.