dsymutil is not called for fortran (and in some cases not correctly for c/c++/ObjC/ObjC++). This appears to be a combination of wrong and dysfunctional specs in config{,/*}/darwin*.h (and possibly a bug in processing %{.xxx|.yyy|.zzz : } ) It could be a regression as far back as 4.3 - (at least in respect of calling for non-Fortran FEs) since the OSX gcc-4.2 does not exhibit this problem with apparently identical specs. see: http://gcc.gnu.org/ml/gcc/2010-04/msg00207.html and: http://gcc.gnu.org/ml/fortran/2010-04/msg00131.html (thanks to Satish Balay for reporting).
I'll take this for now - since I've got a patch in progress that ought to fix it.
Does FSF gcc-4.2 exhibit the problem? Maybe the OSX compiler has local changes in the specs processing.
(In reply to comment #2) > Does FSF gcc-4.2 exhibit the problem? Maybe the OSX compiler has local changes > in the specs processing. OK, it's not a regression - it never worked ;) FSF 4.2 does not have the dsymutil spec. FSF 4.3 does, but it fails in the same way as current trunk. I'll manually compare apple-local-gcc-42/gcc/gcc.c with trunk/gcc/gcc.c as soon as I have a spare moment. As far as Fortran is concerned - this is missing from all versions of the spec (so that needs fixing). The problem at the moment is that adding .f*|.F* doesn't work (whether I expand the * manually or not). In my current fix, I'm intending to remove that part of the spec - since, IMO, it's non-obvious to create a debug sym file for "gcc foo.c -o foo -g " and not for " gcc foo.o -o foo -g " (despite the reasoning behind that - which is clear to compiler cognoscenti but not necessarily compiler users). Of course, that alteration in behavior might not be acceptable to the Darwin maintainers..
see: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html for a proposed resolution to this.
Notes: (temporary work-arounds) 1. for Fortran, one can effect a fix by altering the dsymutil spec in config/darwin.h and config/darwin9.h thus: .c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03: 2. The generic 'failing' is that the spec is looking at only the last item on the c/l -- if that happens to be a source file, the dSYM will be generated. There isn't a generic facility to recognize *any* source file and post a flag (perhaps something worth considering in 4.7). So, you need to make at least one of your source files the last entry on the c/l. 3. To avoid the need for the dSYM at all -- if all you want to do is to debug locally -- just use "-save-temps". 4. Note that there are incompatibilities between the current debug output of FSF gcc and dsymutil - we cannot 'fix' dsymutil as it is closed source. At present, these cause irritating but harmless warnings.
(In reply to comment #5) Firstly, the patch mentioned at comment #2 is withdrawn - it's no longer functional. > 1. for Fortran, one can effect a fix by altering the dsymutil spec in > config/darwin.h and config/darwin9.h thus: > > .c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03: > > 2. The generic 'failing' is that the spec is looking at only the last item on > the c/l -- if that happens to be a source file, the dSYM will be generated. > There isn't a generic facility to recognize *any* source file and post a flag > (perhaps something worth considering in 4.7). > > So, you need to make at least one of your source files the last entry on the > c/l Well this used to work, but no longer does. The recent change to append the libgfortran.spec to the c/l means that one can no longer do this. we need a purpose-made capability to flag (any) source file present on the command line [any language]. > 3. To avoid the need for the dSYM at all -- if all you want to do is to debug > locally -- just use "-save-temps". this is the only current work-around for exes built from source in a single c/l. (NOTE: when the objects are built and linked in separate stages, the dSYM is not required in any event - since the objects are present in the build dir and not deleted until the user does so.)
proposed work-around for 4.6 http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00145.html Note the following web-page describes the intended usage/behavior of dsymutil http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme
Please add a comment with a testcase that fails to work. I tried the obvious one, and when .f is added to darwin9.h, it worked.
(In reply to comment #8) > Please add a comment with a testcase that fails to work. I tried the obvious > one, and when .f is added to darwin9.h, it worked. Indeed, between my comment #6 and yours the (suffix) problem has been resolved (5 days can be a long time in gcc, it seems ;) ). (probably fixed by r167292) so placing: ".c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03:" in config/darwin{,9}.h is now functional - I've tried a variety of representative command lines without fail - so it looks like the underlying issue has been resolved. Of course, residual issues [spurious warnings] with dsymutil are outside our control (other than wrapping the utility in some way). However, other than resolving this, we could enable for Fortran. To resolve the spurious warnings, we will either (a) Have to wrap dsymutil in some script to suppress the spurious messages .. (I made a script referenced in comment #4) .. or (b) Go through the test-suite and put in "prune" lines in the cases that will now fail on "excess errors". -- (a) is somewhat hacky - but does have the advantage that it is a fix in one place rather than distributing stuff around the test-suite.
Jack says that some of the spurious warnings are fixed in Xcode 3.2.3. I have 3.2.4 on my system. Could you update Xcode and see if any we care about remain. If so, please file a Apple bug report. If fixed, we can simply require the newer Xcode. If it won't work on darwin9, and we care, we could have the .f addition in darwin10.h alone. I don't favor the stripping, but I'g go along with a darwin9 stripper and a darwin10 and later no strip version.
(In reply to comment #10) > Jack says that some of the spurious warnings are fixed in Xcode 3.2.3. I have > 3.2.4 on my system. Could you update Xcode and see if any we care about > remain. If so, please file a Apple bug report. If fixed, we can simply > require the newer Xcode. If it won't work on darwin9, and we care, we could > have the .f addition in darwin10.h alone. I don't favor the stripping, but I'g > go along with a darwin9 stripper and a darwin10 and later no strip version. FYI, this was radar 7851516.
The problem dsymutil issues are fixed for darwin10 when using Xcode 3.2.4 and the patch... Index: gcc/config/darwin10.h =================================================================== --- gcc/config/darwin10.h (revision 167446) +++ gcc/config/darwin10.h (working copy) @@ -28,3 +28,12 @@ #undef TARGET_ASM_EMIT_UNWIND_LABEL #define TARGET_ASM_EMIT_UNWIND_LABEL default_emit_unwind_label + +/* Since DWARF2 is default, conditions for running dsymutil are different. */ +/* Xcode 3.2.3 and later have radar 7851516 fixed. */ +#undef DSYMUTIL_SPEC +#define DSYMUTIL_SPEC \ + "%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\ + %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03: \ + %{g*:%{!gstabs*:%{!g0: " DSYMUTIL " %{o*:%*}%{!o:a.out}}}}}}}}}}}}" + http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00289.html Using the same approach in gcc/config/darwin9.h reveals that Xcode 3.1.4 still produces three types of warnings from dsymutil. These are of the form... warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4^M warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4 arning: {0x0000026d} TAG_variable: AT_location( 0x00000000 ) didn't have valid function low pc, the location list will be incorrect.
The second form of the error should have been... warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_lower_bound form = FORM_ref4
Created attachment 22646 [details] patch to expand source types that call dsymutil for darwin9 and later
The testresults on x86_64-apple-darwin9 for the proposed patch expanding the source files types calling dsymutil and the pruning the warnings from dsymutil due to bugs in Xcode 3.1.x are posted at... http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00380.html
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.
dsymutil will generate the same issues for languages already enabled (there are some cases in the c/c++ test-suite on i686-Darwin9). my 0.02 euros: I would prefer to have it enabled for Darwin9 - since that is the last usable case for ppc (if the test-suite prune approach works, then I much prefer that over a hack script). If dsymutil is buggy on Darwin9, there is nothing we can currently do - since I don't imagine that there will be another update for XCode on Darwin9. Not enabling it is simply hiding a problem - not solving it. (maybe one day we'll have time to roll our own and then the dependency will be resolved).
Author: iains Date: Fri Dec 10 10:40:43 2010 New Revision: 167683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167683 Log: dsymutil enabled for Fortran. 2010-12-10 Jack Howarth <howarth@bromo.med.uc.edu> Iain Sandoe <iains@gcc.gnu.org> PR 43751/target gcc: * config/darwin9.h (DSYMUTIL_SPEC): Add fortran source types. testsuite: * lib/prune.exp: Prune dsymutil warnings. libstadc++-v3: * testsuite/lib/prune.exp: Prune dsymutil warnings. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin9.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/prune.exp trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/lib/prune.exp
Fixed. Thanks.
This PR has reappeared after r205679 with warnings of the kind warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_namelist_item: attr = AT_namelist_item form = FORM_ref4 They are silenced with the following change of the regexp added at r167683: --- gcc/testsuite/lib/prune.exp 2013-04-26 10:21:37.000000000 +0200 +++ ../work/gcc/testsuite/lib/prune.exp 2013-12-11 16:42:00.000000000 +0100 @@ -59,7 +59,7 @@ proc prune_gcc_output { text } { # Ignore harmless warnings from Xcode 3.2.x. regsub -all "(^|\n)\[^\n\]*ld: warning: can't add line info to anonymous symbol\[^\n\]*" $text "" text - regsub -all "(^|\n)\[^\n\]*warning: DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*_bound\[^\n\]*FORM_ref4\[^\n\]*" $text "" text + regsub -all "(^|\n)\[^\n\]*warning: DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*FORM_ref4\[^\n\]*" $text "" text regsub -all "(^|\n)\[^\n\]*warning:\[^\n\]*TAG_variable: AT_location\[^\n\]*didn't have valid function low pc\[^\n\]*" $text "" text # Ignore harmless warnings from Xcode 4.0. I hope this change will survive any fix for pr59438!
Author: dominiq Date: Wed Apr 2 08:34:45 2014 New Revision: 209016 URL: http://gcc.gnu.org/viewcvs?rev=209016&root=gcc&view=rev Log: 2014-04-02 Dominique d'Humieres <dominiq@lps.ens.fr> PR target/43751 * lib/prune.exp: Modify the regular express to prune the new warnings introduced by r205679 on darwin9. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/prune.exp
Author: dominiq Date: Fri Apr 4 06:43:56 2014 New Revision: 209070 URL: http://gcc.gnu.org/viewcvs?rev=209070&root=gcc&view=rev Log: 2014-03-26 Dominique d'Humieres <dominiq@lps.ens.fr> PR target/43751 * lib/prune.exp: Modify the regular express to prune the new warnings introduced by r205679 on darwin9. Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_en.f90
Wrong entry.