------- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-04-12
01:54 -------
The response from the dsymutil maintainer was...
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]
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]
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254
