[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.

["howarth at nitro dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>]

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.