Bootstrap fails at revision 151873 on *-apple-darwin9 with ... checking for long long... yes checking size of long long... configure: error: in `/opt/gcc/darwin_buildw/gcc': configure: error: cannot compute sizeof (long long) See `config.log' for more details. make[2]: *** [configure-stage3-gcc] Error 77 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 Looking at the config.log files I see: configure:5754: /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w /i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/i68 6-apple-darwin9/sys-include -o conftest -g -O2 -fomit-frame-pointer conftest.c >&5 Assertion failed: (!"Unknown one-operand"), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 157 1. xgcc: Internal error: Abort trap (program dsymutil) Last successful builds: 151801 on i686-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01688.html) and 151771 on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01689.html). This PR may be a duplicate of pr41395, but the symptoms are different along with the revision numbers. See also http://gcc.gnu.org/ml/gcc-regression/2009-09/msg00190.html for a possible culprit.
Assertion failed: (!"Unknown one-operand"), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 157 1. xgcc: Internal error: Abort trap (program dsymutil) this means this is a darwin bug, dsymutil abort()s. Please report to apple instead.
> this means this is a darwin bug, dsymutil abort()s. Please report to apple instead. What should I report to apple? gcc 4.5.0 is working probably at least up to revision 151807 (currently building libjava) then some change in a later revision triggered the problem: the change is not in the apple side, but in the gcc one. This may uncover an apple bug, but in the present situation I don't see what I should report to apple and expect an answer from them. So please leave the pr open for the moment.
When bootstrapping r151807 will finish (couple hours from now). I am planning to bootstrap r151815. What is the estimated likelihood that the problem is triggered by * dwarf2out.c (loc_descriptor): Emit DW_OP_stack_value and DW_OP_implicit_value even without dwarf_version 4. ?
Yes, probably the apple tools barf on the new dwarf opcodes. Please report the issue to them. A GCC side fix would be to add an option to restrict dwarf to dwarf2 and turn that option on by default for darwin.
Same problem on x86_64-apple-darwin10 with current gcc trunk... onfigure:5749: checking size of long long configure:5754: /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/sys-include -o conftest -g -O2 conftest.c >&5 Assertion failed: (!"Unknown one-operand"), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 1571. xgcc: Internal error: Abort trap (program dsymutil)
This seems strange to me. If I create the offending conftest.c test file and execute... /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/sys-include -o conftest -g -O2 --save-temps conftest.c I get... Assertion failed: (!"Unknown one-operand"), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 1571. xgcc: Internal error: Abort trap (program dsymutil) whereas if I then use the preprocessed source file to execute... /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/sys-include -o conftest -g -O2 conftest.i I get no error and a conftest executable is created that runs without errors. This would seem to point back at the xgcc as at fault and not dsymutil, no?
Created attachment 18612 [details] conftest.c file created on x86_64-apple-darwin10
Created attachment 18613 [details] preprocessed source for conftest.c created on x86_64-apple-darwin10
Created attachment 18614 [details] assembly file for conftest.c created with --save-temps on x86_64-apple-darwin10
I should also point out that --save-temps produces identical conftest.s files whether xgcc compiles from conftest.c or conftest.i. Only it errors when starting from conftest.c but not conftest.i (which was obtained from the first step with --save-temps).
see my comment #10 on PR41395 and note that this bug also shows on powerpc-apple-darwin9. It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the likelihood of a straight dsymutil bug).
(In reply to comment #11) > see my comment #10 on PR41395 and note that this bug also shows on > powerpc-apple-darwin9. > It DOES NOT show on powerpc-apple-darwin8 (which makes one less sure about the > likelihood of a straight dsymutil bug). correction: the DWARFdSYM.cpp:1260: failed assertion `!"Unknown one-operand"' *IS* occurring on Darwin8 - but it is not causing a bootstrap fail. note that on Darwin9: In file included from ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde-darwin.c:35:0: ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h: In function ‘last_fde’: ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h:173:3: warning: cast discards qualifiers from pointer target type c.f. Darwin8: In file included from ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde-darwin.c:35:0: ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h: In function 'last_fde': ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h:173:3: warning: cast discards qualifiers from pointer target type
The culprit is indeed r151815. Reverting the change after having updated to r151893 on i686-apple-darwin9 ( r151895 on powerpc-apple-darwin9) allows a successful bootstrap (currently building the libs on powerpc). In http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html the patch is motivated by: > I think the important question is whether older debuggers would be able > to deal gracefully with these location entries or constant values. I > understand they're supposed to, and I have no evidence that GDB isn't, so > I offer this patch to revert the last-minute addition of tests for > dwarf_version >= 4 in the VTA merge patch. > > Should I check it in so that we can get a better idea of what, if > anything, breaks? Apparently the changes affect more than GDB. So now that you have "get a better idea of what, if anything, breaks" it seems appropriate to revert them. > Yes, probably the apple tools barf on the new dwarf opcodes. Please report the > issue to them. As far as I understand the problem, I do not see why tools not designed to accept "dwarf_version 4" can be blamed for that (it would be like blaming the CD player in my car for not reading MP3 CDs). > A GCC side fix would be to add an option to restrict dwarf to dwarf2 and turn that option on by > default for darwin. What is the difference with reverting the patch?
Reverting r151815 also eliminates the bootstrap breakage on x86_64-apple-darwin10. Nice catch.
You might want to change the Summary here to "[4.5 Regression] Bootstrap broken by r151815 on *-apple-darwin9"
> As far as I understand the problem, I do not see why tools not designed to > accept "dwarf_version 4" can be blamed for that (it would be like blaming the > CD player in my car for not reading MP3 CDs). But you would complain to them if it was eating your MP3 CDs, right? ;) As specified they should ignore dwarf codes they do not understand, not assert on them. Please if you care report this issue to apple (it's probably enough to send them along a file that crashes their tool). Instead of reverting the patch we should add a -gstrict-dwarf[23] switch that darwin can use by default instead.
(In reply to comment #16) > As specified they should ignore dwarf codes they do not understand, not assert > on them. Please if you care report this issue to apple (it's probably enough > to send them along a file that crashes their tool). > There still is an oddity here. I can trigger this problem in current gcc trunk with a conftest.c but not with a conftest.i (comment 6). This suggest it might be difficult to construct a standalone testcase since the assembly files created from both methods are identical (but only the first case results in an asset...weird).
(In reply to comment #17) > > > There still is an oddity here. I can trigger this problem in current gcc trunk > with a conftest.c but not with a conftest.i (comment 6). > dsymutil does not get run when compiling conftest.i The specs file has: %{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S: %%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: %%{g*:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!o:a.out}}}}}}}}}}}} So, as far as I can tell, dsymutil only gets run for files with the extensions .c,.cc,.C,.cpp,.cp,.c++,.cxx,.CPP,.m and .mm
(In reply to comment #16) firstly, backing out of all mods to dwarf2out.c after 151814 both allows the bootstrap to complete and checking the log files shows no dsymutil fails powerpc-apple-darwin8, i686-apple-darwin9 > Instead of reverting the patch [this might not be quite enough; backing out of only 151814->151815 for trunk version 151904 produced a working bootstrap but with still some dsymutil fails]. we should add a -gstrict-dwarf[23] switch > that darwin can use by default instead. Please can we do this; even if there is a fix applied to darwin10/9 dsymutil we are unlikely to see a fix applicable to darwin8 since active development is now on darwin10.
Wonder why gcc on darwin should always work around darwin toolchain bugs, but on most other OSes if you have bugs in tools, you just require those bugs to be fixed, gcc doesn't work around them. What is so special about darwin? That said, -gstrict-dwarf (perhaps without a version, just saying you never want any stuff beyond the selected dwarf version) is something I can live with.
Changed the subject to reflect the comments. > [this might not be quite enough; backing out of only 151814->151815 for trunk > version 151904 produced a working bootstrap but with still some dsymutil > fails]. I don't see that at revision 151893, but with revision 151907 I see: ... ld warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from .libs/libstdc++.lax/libsupc++convenience.a/pbase_type_info.o libtool: link: dsymutil .libs/libstdc++.6.dylib || : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. ../libtool: line 7996: 5815 Abort trap dsymutil .libs/libstdc++.6.dylib libtool: link: (cd ".libs" && rm -f "libstdc++.dylib" && ln -s "libstdc++.6.dylib" "libstdc++.dylib") ... libtool: link: dsymutil .libs/libgfortran.3.dylib || : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. ./libtool: line 7996: 60055 Abort trap dsymutil .libs/libgfortran.3.dylib libtool: link: (cd ".libs" && rm -f "libgfortran.dylib" && ln -s "libgfortran.3.dylib" "libgfortran.dylib") ... libtool: link: dsymutil .libs/libobjc-gnu.2.dylib || : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. warning: {0x000047a9} TAG_formal_parameter: AT_location( 0x00000000 ) didn't have valid function low pc, the location list will be incorrect. ./libtool: line 7988: 71819 Abort trap dsymutil .libs/libobjc-gnu.2.dylib ... libtool: link: dsymutil .libs/libffi.4.dylib || : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. ./libtool: line 7982: 77537 Abort trap dsymutil .libs/libffi.4.dylib libtool: link: (cd ".libs" && rm -f "libffi.dylib" && ln -s "libffi.4.dylib" "libffi.dylib") ... libtool: link: dsymutil .libs/libgcj.11.dylib || : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. ./libtool: line 7996: 79525 Abort trap dsymutil .libs/libgcj.11.dylib libtool: link: (cd ".libs" && rm -f "libgcj.dylib" && ln -s "libgcj.11.dylib" "libgcj.dylib") ... libtool: link: dsymutil .libs/libgcj.11.dylib || : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. ./libtool: line 7996: 50550 Abort trap dsymutil .libs/libgcj.11.dylib libtool: link: (cd ".libs" && rm -f "libgcj.dylib" && ln -s "libgcj.11.dylib" "libgcj.dylib") ... Looking in more details I get [ibook-dhum] libstdc++-v3/src/.libs% dsymutil libstdc++.6.dylib Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. Abort [ibook-dhum] libstdc++-v3/x86_64/src/.libs% dsymutil libstdc++.6.dylib Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. Abort [ibook-dhum] libgfortran/.libs% dsymutil libgfortran.3.dylib warning: {0x0004c5b4} TAG_formal_parameter: AT_location( 0x0004e95e ) didn't have valid function low pc, the location list will be incorrect. [ibook-dhum] x86_64/libgfortran/.libs% dsymutil libgfortran.3.dylib Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. Abort [ibook-dhum] libobjc/.libs% dsymutil libobjc-gnu.2.dylib warning: {0x000047a9} TAG_formal_parameter: AT_location( 0x00000000 ) didn't have valid function low pc, the location list will be incorrect. Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. Abort [ibook-dhum] x86_64/libobjc/.libs% dsymutil libobjc-gnu.2.dylib This is likely due to revision 151901 and seems harmless on the fortran tests I have done (I did not regtested yet).
Dominique has confirmed what I've found, that some changes beyond 151814->151815 are also significant. test results for powerpc-apple-darwin8 and i686-apple-darwin9 http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01885.html http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01886.html to Jack; your test case does NOT fail with this build on either powerpc D8 or i686 D9. Perhaps this gives us a starting point for producing a test-case that (a) fails on darwin toolset and (b) is demonstrably correct by some other means -- i.e. bug is squarely in the toolset. these particular tools are not currently open sourced - and therefore it is impossible for us to require them to be fixed on any particular version of darwin (if they were open I'd gladly volunteer to attempt the fix myself). To that end I have enquired on darwin-dev as to the likelihood of them being open-sourced.
Created attachment 18621 [details] gcc45-pr41405.patch Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless explicitly set on the command line). I went through all the DWARF 3 and DWARF 4 additions used by dwarf2out.c, except DW_CFA_* so far.
> Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless > explicitly set on the command line). I went through all the DWARF 3 and DWARF > 4 additions used by dwarf2out.c, except DW_CFA_* so far. Jakub, Thanks for the patch. For what I understand (very little) it mostly reverts revision 151815 by replacing the removed 'dwarf_version >= 4' by '(dwarf_version >= 4 || !dwarf_strict)'. So I still don't understand why revision 151815 is not reverted NOW in order to allow darwin to bootstrap with trunk. Then there will be plenty of time to apply your patch after it has been discussed by competent people. It would also be of interest to document in PLAIN English why it is so important to include dwarf4 stuff for systems that do not support it. I am currently regetesting my tree, but I'll test your patch ASAP.
(In reply to comment #23) > Created an attachment (id=18621) [edit] > gcc45-pr41405.patch thanks for the patch. I bootstrapped i686-apple-darwin successfully with the addition of dwarf_strict=1; to darwin_override_options() which is invoked from SUBSUBTARGET_OVERRIDE_OPTIONS unfortunately, there are still some ASSERTS when processing libgfortran, libgnu-obj, libjg. I wonder if that's because I've not got the dwarf_strict=1; in the correct place - and I'm working my way through the options processing..
(In reply to comment #23) > Created an attachment (id=18621) [edit] > gcc45-pr41405.patch as pre previous comment - this bootstraps OK i686-apple-darwin9. 1/ but the error output contains the following : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFdSYM.cpp, line 3157. ./libtool: line 7982: 98179 Abort trap dsymutil .libs/libffi.4.dylib ditto: dsymutil .libs/libgfortran.3.dylib dsymutil .libs/libobjc-gnu.2.dylib dsymutil .libs/libgcj.11.dylib 1/ does that point to any specific area to check? 2/ I guess it's also possible that there's a bug in the darwin-specific code that emits debug info for mach-o. Where should one look for information that would allow one to prove that the output is 'correctly formed'? we'll need to do that anyway in order to formulate a radar.
I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so likely -gstrict-dwarf wasn't used when compiling something that has been linked into those libraries. No idea if Mach-O has any tools similar to readelf that would allow you to dump the debug info of object files, if not, you'll need to check for it at the assembler level (-save-temps plus -dA).
(In reply to comment #27) > I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so > likely -gstrict-dwarf wasn't used when compiling something that has been linked > into those libraries. (two bootstraps later...) I jammed an Init(1) into the flag line and the four fail cases still appear. With current trunk - and dwarf2out.c from 151814 there are no fails. > No idea if Mach-O has any tools similar to readelf that would allow you to dump > the debug info of object files, if not, you'll need to check for it at the I'll have to see what dwarfdump can do (one might expect it to fail in the same way as dsymtuil) - but first we need a reliable simple failing case. > assembler level (-save-temps plus -dA). downloaded the dwarf2 and dwarf3 specs... ah well, there's always hexdump ;-)
Do we even know for certain that older versions of bintuils really work properly with the newer dwarf3/dwarf4? I wonder how much of the general instability in the recent bootstraps might be related these types of changes.
Yes, we know for certain binutils are fine.
OK. this is what I've done (a) bootstrapped with Jakub's path but modified thus >> Common Report Var(dwarf_strict) Init(1) - bootstrap succeeds (with the four errors mentioned in #26). (b) I then hand edited gcc/options.c to set dwarf_strict=0; and re-made xgcc. Now I have a built complier that responds to the -gstrict_dwarf flag. so I made a very simple source file: int testfunc(void) { int ; i=1; return i; } I can compile this with/without -gstrict-dwarf and cmp says the .o files are the same. -save-temps -fverbose-asm says that gstrict-dwarf is being turned on & off. dwarfdump succeeds with everything but --debug-frame :Assertion failed: (reg_state_pos != cie->initial_state.regs.end()), function ParseInstructions, (note that for this simple file the debug-str; segment is empty - which is the error case in the four lib ones). any guru gonna point me to where to go next ... it's really difficult to know where the problem really lies right now.
Updated patch: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01477.html You used a too simple testcase which doesn't need any of the DWARF4 additions. Use a more complicated one, e.g. try the gcc.dg/guality/ testcases with -g{,no-}strict-dwarf.
Subject: Bug 41405 Author: jakub Date: Tue Sep 22 13:22:15 2009 New Revision: 151978 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151978 Log: PR bootstrap/41405 * dwarf2out.c (base_type_die, record_type_tag, gen_subprogram_die, add_call_src_coords_attributes, add_high_low_attributes, gen_compile_unit_die, gen_type_die_with_usage force_decl_die, gen_decl_die, dwarf2out_imported_module_or_decl_1, dwarf2out_finish, dwarf2out_imported_module_or_decl): Avoid using DWARF3 additions when -gdwarf-2 -gstrict-dwarf. (loc_list_from_tree): Likewise. Avoid using DWARF4 additions when -gdwarf-[23] -gstrict-dwarf. (address_of_int_loc_descriptor, loc_descriptor, loc_list_for_address_of_addr_expr_of_indirect_ref): Avoid using DWARF4 additions when -gdwarf-[23] -gstrict-dwarf. * common.opt (gno-strict-dwarf, gstrict-dwarf): New options. * gfortran.dg/debug/pr37738.f: Add -gno-strict-dwarf to dg-options. * gfortran.dg/debug/pr35154-dwarf2.f: Likewise. * g++.dg/debug/dwarf2/explicit-constructor.C: Likewise. * g++.dg/debug/dwarf2/imported-module-2.C: Likewise. * g++.dg/debug/dwarf2/imported-module-3.C: Likewise. * g++.dg/debug/dwarf2/imported-module-4.C: Likewise. * g++.dg/debug/dwarf2/namespace-1.C: Likewise. * objc.dg/dwarf-2.m: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/explicit-constructor.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-2.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-3.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/imported-module-4.C trunk/gcc/testsuite/g++.dg/debug/dwarf2/namespace-1.C trunk/gcc/testsuite/gfortran.dg/debug/pr35154-dwarf2.f trunk/gcc/testsuite/gfortran.dg/debug/pr37738.f trunk/gcc/testsuite/objc.dg/dwarf-2.m
(In reply to comment #32) > Updated patch: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01477.html thanks - actually I was trying this - but in the end updated to 151978... with BOOT_CFLAGS="-g -gdwarf-2 -gstrict-dwarf -O2" and CFLAGS_FOR_TARGET the same/ Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1objplus-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs i686-apple-darwin9/libstdc++-v3/src/future.o differs i686-apple-darwin9/libstdc++-v3/src/system_error.o differs i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs make[2]: *** [compare] Error 1 > You used a too simple testcase which doesn't need any of the DWARF4 additions. > Use a more complicated one, e.g. try the gcc.dg/guality/ testcases with > -g{,no-}strict-dwarf. well that's true - but I'd stopped there since even that simplistic case was giving errors with dwarfdump --debug-frame once we figure out how to get bootstrap working again .. I'll do the gcc.dg/guality testcases as you suggest
BOOT_CFLAGS="-g -gdwarf-2 -gstrict-dwarf -O2" likely doesn't work with bootstrap-debug. Try just BOOT_CFLAGS="-gdwarf-2 -gstrict-dwarf -O2".
Remove -gdwarf-2 as well. -gdwarf-2 is the same as -g when dwarf_version defaults to 2 (which is true on the trunk). Easiest quick hack to turn -gstrict-dwarf on is add Init(1) to gno-strict-dwarf in common.opt (that's how I've been testing it).
(In reply to comment #36) > Remove -gdwarf-2 as well. -gdwarf-2 is the same as -g when dwarf_version > defaults to 2 (which is true on the trunk). > Easiest quick hack to turn -gstrict-dwarf on is add Init(1) to gno-strict-dwarf > in common.opt (that's how I've been testing it). yeah I was adding Init(1) yesterday. I did that and bootstrapped again; double-checked and the flags are correctly init-ed (=2 and =1). NO CHANGE (2 fails x 4 on compare-debug), so something else is broken. I'll try and investigate.. but time is shot now.
> Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1objplus-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > Bootstrap comparison failure! > i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs > i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs > i686-apple-darwin9/libstdc++-v3/src/future.o differs > i686-apple-darwin9/libstdc++-v3/src/system_error.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs > make[2]: *** [compare] Error 1 FWIW powerpc-apple-darwin8 exhibits the same phenomenon.
object differences currently causing bootstrap fail - these look unrelated to the original bug: .. anyone throw any light on this? stripped future.o from stage 2 000007e0 63 5f 5f 5f 76 33 5f 73 72 63 5f 66 75 74 75 72 |c___v3_src_futur| 000007f0 65 2e 63 63 5f 30 30 30 30 30 30 30 30 5f 34 37 |e.cc_00000000_47| 00000800 44 39 32 31 34 32 32 31 66 75 74 75 72 65 5f 65 |D9214221future_e| 00000810 72 72 6f 72 5f 63 61 74 65 67 6f 72 79 45 00 00 |rror_categoryE..| stripped future.o from stage 3 000007e0 63 5f 5f 5f 76 33 5f 73 72 63 5f 66 75 74 75 72 |c___v3_src_futur| 000007f0 65 2e 63 63 5f 30 30 30 30 30 30 30 30 5f 45 35 |e.cc_00000000_E5| 00000800 45 38 41 43 44 37 32 31 66 75 74 75 72 65 5f 65 |E8ACD721future_e| 00000810 72 72 6f 72 5f 63 61 74 65 67 6f 72 79 45 00 00 |rror_categoryE..| === stripped system_error.o from stage 2 000007a0 30 30 30 5f 37 37 34 44 41 30 30 45 32 32 67 65 |000_774DA00E22ge| 000007b0 6e 65 72 69 63 5f 65 72 72 6f 72 5f 63 61 74 65 |neric_error_cate| 000007c0 67 6f 72 79 45 00 00 00 00 00 00 00 00 00 00 00 |goryE...........| 000007d0 4e 38 39 5f 47 4c 4f 42 41 4c 5f 5f 4e 5f 2e 2e |N89_GLOBAL__N_..| 000007e0 5f 2e 2e 5f 2e 2e 5f 2e 2e 5f 67 63 63 5f 34 5f |_.._.._.._gcc_4_| 000007f0 35 5f 72 65 67 74 65 73 74 5f 6c 69 62 73 74 64 |5_regtest_libstd| 00000800 63 5f 5f 5f 76 33 5f 73 72 63 5f 73 79 73 74 65 |c___v3_src_syste| 00000810 6d 5f 65 72 72 6f 72 2e 63 63 5f 30 30 30 30 30 |m_error.cc_00000| 00000820 30 30 30 5f 37 37 34 44 41 30 30 45 32 31 73 79 |000_774DA00E21sy| stripped system_error.o from stage 3 000007a0 30 30 30 5f 35 39 44 36 31 37 37 43 32 32 67 65 |000_59D6177C22ge| 000007b0 6e 65 72 69 63 5f 65 72 72 6f 72 5f 63 61 74 65 |neric_error_cate| 000007c0 67 6f 72 79 45 00 00 00 00 00 00 00 00 00 00 00 |goryE...........| 000007d0 4e 38 39 5f 47 4c 4f 42 41 4c 5f 5f 4e 5f 2e 2e |N89_GLOBAL__N_..| 000007e0 5f 2e 2e 5f 2e 2e 5f 2e 2e 5f 67 63 63 5f 34 5f |_.._.._.._gcc_4_| 000007f0 35 5f 72 65 67 74 65 73 74 5f 6c 69 62 73 74 64 |5_regtest_libstd| 00000800 63 5f 5f 5f 76 33 5f 73 72 63 5f 73 79 73 74 65 |c___v3_src_syste| 00000810 6d 5f 65 72 72 6f 72 2e 63 63 5f 30 30 30 30 30 |m_error.cc_00000| 00000820 30 30 30 5f 35 39 44 36 31 37 37 43 32 31 73 79 |000_59D6177C21sy|
Iain, that is odd. I had no problems last night at r151946 on x86_64-apple-darwin10. Why don't you try r151946 with Jakub's patch applied from... http://gcc.gnu.org/viewcvs?view=revision&revision=151978 to see if the breakage still exists.
> Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1objplus-checksum.o differs > warning: gcc/cc1plus-checksum.o differs > Bootstrap comparison failure! > i686-apple-darwin9/libstdc++-v3/src/.libs/future.o differs > i686-apple-darwin9/libstdc++-v3/src/.libs/system_error.o differs > i686-apple-darwin9/libstdc++-v3/src/future.o differs > i686-apple-darwin9/libstdc++-v3/src/system_error.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/future.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs/system_error.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/future.o differs > i686-apple-darwin9/x86_64/libstdc++-v3/src/system_error.o differs > make[2]: *** [compare] Error 1 This seems weird: AFAIK libstdc++-v3 is not built at stage 2. So what is compared to what?
Are you building with --enable-build-with-cxx or something similar? libstdc++-v3 isn't normally compared. The difference you are seeing is likely related to different random seed, you'd need to pass the same -frandom-seed=XXXX in both stage2 and stage3 builds...
(In reply to comment #42) > Are you building with --enable-build-with-cxx or something similar? > libstdc++-v3 isn't normally compared. The difference you are seeing is likely > related to different random seed, you'd need to pass the same > -frandom-seed=XXXX in both stage2 and stage3 builds... --enable-stage1-languages=c,c++ AFAIK this is now necessary when building in-tree GMP/MPFR . If that requirement has been lifted.. then this problem will evaporate (or I can take a diff. approach to building GMP/MPFR).
Is there a trick to getting BOOT_CFLAGS set from gcc/config/t-darwin? Simply adding... BOOT_CFLAGS = -gdwarf-3 -gstrict-dwarf -O2 doesn't work. it always is left as -O2 -g during the build.
Okay, using r152049 with... --- gcc-4.5-20090922/gcc/common.opt.org 2009-09-22 20:58:14.000000000 -0400 +++ gcc-4.5-20090922/gcc/common.opt 2009-09-22 20:58:51.000000000 -0400 @@ -1473,7 +1473,7 @@ Generate debug information in extended STABS format gno-strict-dwarf -Common RejectNegative Var(dwarf_strict,0) +Common RejectNegative Var(dwarf_strict,0) Init(1) Emit DWARF additions beyond selected version gstrict-dwarf allows x86_64-apple-darwin10 to bootstrap without additional patches. We still need some graceful way to enable this for darwin automatically. Passing -gstrict-dwarf on BOOT_CFLAGS doesn't seem to survive through the entire build process...at least in my attempts.
Created attachment 18633 [details] failed buildlog for x86_64-apple-darwin10 Failed build log from x86_64-apple-darwin10 when using... make -j $num_cpu BOOT_CFLAGS="-O2 -g -gstrict-dwarf" instead of patching common.opt to have Init(1) on gno-strict-dwarf (which always builds completely).
The build failure appears to be at... checking for _FILE_OFFSET_BITS value needed for large files... configure: error: unsupported system, cannot find sizeof (omp_lock_t) no when passing BOOT_CFLAGS="-O2 -g -gstrict-dwarf" to make. Do we also need CFLAGS_FOR_TARGET="-O2 -g -gstrict-dwarf" as well?
(In reply to comment #43) > (In reply to comment #42) > > Are you building with --enable-build-with-cxx or something similar? confirmed. building with: out-of-tree gmp/mpfr and --enable-stage1-languages=c bootstrap completes with same observation as #26
With the patch in comment #45 I bootstrapped revision 152032 on powerpc-apple-darwin9. I still have: 17913 - libtool: link: dsymutil .libs/libstdc++.6.dylib || : 17914 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 17915 + ../libtool: line 7996: 84744 Abort trap dsymutil .libs/libstdc++.6.dylib 20787 - libtool: link: dsymutil .libs/libstdc++.6.dylib || : 20788 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 20789 + ../libtool: line 7996: 88228 Abort trap dsymutil .libs/libstdc++.6.dylib 24341 - libtool: link: dsymutil .libs/libgfortran.3.dylib || : 24342 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 24343 + ./libtool: line 7996: 26398 Abort trap dsymutil .libs/libgfortran.3.dylib 26886 - libtool: link: dsymutil .libs/libgfortran.3.dylib || : 26887 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 26888 + ./libtool: line 7996: 43162 Abort trap dsymutil .libs/libgfortran.3.dylib 27618 - libtool: link: dsymutil .libs/libgcjgc.1.dylib || : 27619 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 27620 + ./libtool: line 7996: 53231 Abort trap dsymutil .libs/libgcjgc.1.dylib 34867 - libtool: link: dsymutil .libs/libgcj.11.dylib || : 34868 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 34869 + ./libtool: line 7996: 39266 Abort trap dsymutil .libs/libgcj.11.dylib 39266 - libtool: link: dsymutil .libs/libgcj.11.dylib || : 39267 : Assertion failed: (orig_str), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 3619. 39268 + ./libtool: line 7996: 86779 Abort trap dsymutil .libs/libgcj.11.dylib (slightly different to what I have reported in comment #21).
(In reply to comment #42) > Are you building with --enable-build-with-cxx or something similar? > libstdc++-v3 isn't normally compared. The difference you are seeing is likely > related to different random seed, you'd need to pass the same > -frandom-seed=XXXX in both stage2 and stage3 builds... > Jakub, I also noticed this thread... http://gcc.gnu.org/ml/gcc/2009-09/msg00467.html which suggests that mangling issues exist on other targets as well for --enable-build-with-cxx, no?
Is there anyway to redefine or adjust gno-strict-dwarf at a target specific level so that for a given target that option could be set to Init(1)? Having to pass this through BOOT_CFLAGS seems suboptimal because, even if we set those in t-darwin or such, a user might accidentally clear those while testing other BOOT_CFLAGS permutations and not understand why the build was breaking.
(In reply to comment #51) > Is there anyway to redefine or adjust gno-strict-dwarf at a target specific > level so that for a given target that option could be set to Init(1)? Having to > pass this through BOOT_CFLAGS seems suboptimal because, even if we set those in > t-darwin or such, a user might accidentally clear those while testing other > BOOT_CFLAGS permutations and not understand why the build was breaking. see this thread: http://gcc.gnu.org/ml/gcc/2009-09/msg00460.html and this: http://gcc.gnu.org/ml/gcc/2009-09/msg00468.html
So then the most robust approach would be to add your patch to enable dwarf debugging on darwin8 and then add... gno-strict-dwarf Common RejectNegative Var(dwarf_strict,0) Init(1) Emit DWARF additions beyond selected version to gcc/config/darwin.opt, no? I guess we do have to worry about whether powerpc-darwin understands dwarf3. Perhaps we might need to also default gdwarf2 on for powerpc-darwin in for that target as well.
For target masks, the target override routine checks the *_explicit flag and only changes it to the default if it wasn't explicit. For other variables, usually the variable is initialized to some other value (-1 usually) in *.opt, then the target has a chance to override it in its override routine (if it is still that special value at that point) and finally the generic code sets it to the default value if it is still the special value.
Subject: Bug 41405 Author: jakub Date: Wed Sep 23 14:52:20 2009 New Revision: 152076 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152076 Log: PR bootstrap/41405 * doc/invoke.texi: Document -gstrict-dwarf and -gno-strict-dwarf. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
(In reply to comment #54) > For target masks, the target override routine checks the *_explicit flag and > only changes it to the default if it wasn't explicit. > For other variables, usually the variable is initialized to some other value > (-1 usually) in *.opt, then the target has a chance to override it in its > override routine (if it is still that special value at that point) and finally > the generic code sets it to the default value if it is still the special value. > Jakub, Can you point us to a specific example of this being done in the gcc sources we can get the syntax correct? If I execute "grep -R _explicit gcc/config", I get a lot of matches but am unsure if they are doing what you describe.
Can we just add... ;; enable gstrict-dwarf as default TargetSave int gstrict_dwarf_explicit=1 in darwin.opt to achieve this?
Created attachment 18640 [details] cause darwin to default to strict dwarf control. Try this.. ChangeLog: 2009-09-23 Iain Sandoe <iain.sandoe@sandoe-acoustics.co.uk> *gcc/common.opt initialize dwarf_strict to -1 as an unset value. *gcc/toplev.c catch unset dwarf_strict and set to 0 *gcc/config/darwin.c catch unset dwarf_strict and set to 1 on darwin.
Iain, Your patch bootstraps x86_64-apple-darwin10 fine. Can you please send that with the ChangeLog to gcc-patches. Hopefully it will be sufficient to get the Apple regress server building again.
Iain, If you have opened a radar report for the dsymutil issue, you might want to put the radar number in the comment as well.
I have followed a path different from the one in comment #58, trying to use -gstrict-dwarf during bootstrap. For that I have made the following changes: diff -uN ../_gcc_clean/config/mh-intel-darwin config/mh-intel-darwin --- ../_gcc_clean/config/mh-intel-darwin 1970-01-01 01:00:00.000000000 +0100 +++ config/mh-intel-darwin 2009-09-23 23:02:59.000000000 +0200 @@ -0,0 +1,5 @@ +# Set strict-dwarf for Darwin + +BOOT_CFLAGS += -gstrict-dwarf +CFLAGS_FOR_TARGET += -gstrict-dwarf +CFLAGS += -gstrict-dwarf diff -uN ../_gcc_clean/config/mh-ppc-darwin config/mh-ppc-darwin --- ../_gcc_clean/config/mh-ppc-darwin 2008-02-25 11:00:23.000000000 +0100 +++ config/mh-ppc-darwin 2009-09-23 23:56:42.000000000 +0200 @@ -2,4 +2,6 @@ # position-independent-code -- the usual default on Darwin. This fix speeds # compiles by 3-5%. -BOOT_CFLAGS += -mdynamic-no-pic +BOOT_CFLAGS += -mdynamic-no-pic -gstrict-dwarf +CFLAGS_FOR_TARGET += -gstrict-dwarf +CFLAGS += -gstrict-dwarf --- ../_gcc_clean/configure 2009-09-22 20:04:27.000000000 +0200 +++ configure 2009-09-23 13:50:29.000000000 +0200 @@ -3655,6 +3655,12 @@ powerpc-*-darwin*) host_makefile_frag="config/mh-ppc-darwin" ;; + i[3456789]86-*-darwin*) + host_makefile_frag="config/mh-intel-darwin" + ;; + x86_64-*-darwin[912]*) + host_makefile_frag="config/mh-intel-darwin" + ;; powerpc-*-aix*) host_makefile_frag="config/mh-ppc-aix" ;; With these changes I have successfully bootstrapped revision 152076 on i686-apple-darwin9 and I am currently bootstrapping revision 152100 on powerpc-apple-darwin9 (modulo pr41457). I have found that the change 'CFLAGS_FOR_TARGET += -gstrict-dwarf' is needed to bootstrap, while the change 'CFLAGS += -gstrict-dwarf' (nor the others) does not allow to propagate -gstrict-dwarf for the libraries, hence "Assertion failed: (!"Unknown one-operand")..." for them.
See also http://gcc.gnu.org/ml/gcc/2009-09/msg00500.html .
(In reply to comment #62) > See also http://gcc.gnu.org/ml/gcc/2009-09/msg00500.html . > Dominique, Have you tried current gcc trunk with... http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01686.html I'll try a build of i686-apple-darwin10 tonight to make sure that target is okay.
Subject: Bug 41405 Author: rth Date: Thu Sep 24 17:02:29 2009 New Revision: 152127 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152127 Log: PR bootstrap/41405 * common.opt: Initialize dwarf_strict to -1. * toplev.c (process_options): Catch unset dwarf_strict and set to 0 for all targets not overriding. * config/darwin.c (darwin_override_options): Catch unset dwarf_strict and override to 1. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/config/darwin.c trunk/gcc/toplev.c
(In reply to comment #64) > Subject: Bug 41405 > > Author: rth > Date: Thu Sep 24 17:02:29 2009 > New Revision: 152127 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152127 thanks Richard, bootstrapped and regtested on powerpc-apple-darwin8 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02242.html i686-apple-darwin9 : http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02243.html AFAICT the remaining dsymutil problem is only affecting the availability of debug symbols for the libs;
Dominique, Can we close this bug as fixed now? The regress server is churning away again.
I have opened pr41473 to track the remaining issue with dsymutil. Closing this PR as fixed. Please reopen if you disagree.