> From: Steve Ellcey <s...@cup.hp.com> > Date: Fri, 18 Nov 2011 18:24:22 +0100
> This patch fixes the IA64 bootstrap when building libunwind. When using > -fexceptions libunwind will have a reference to __gcc_personality_v0 and > the bootstrap fails, using -fno-exceptions fixes this. This problem > started with r181172, Michael Matz's fix to mark objects death at end of > scope. > > Tested on IA64 HP-UX and Linux. > > While this change isn't in an ia64 specific file, ia64 is the only > platform affected Apparently wrong... > because no other platform defines LIBUNWIND in order > to build a separate unwind library. ...as the patch somehow affects all of libgcc, verified by diffing the build-logs around this commit. > So I will go ahead and check it in > if there are no objections. > > Steve Ellcey > s...@cup.hp.com > > > 2011-11-18 Steve Ellcey <s...@cup.hp.com> > > * Makefile.in (c_flags): Set to -fno-exceptions to build libunwind. This patch caused the state for cris-elf for my autotester to go from regress-4 to regress-389 and yes, that looks like a good deal if not all of the exception-specific tests. Before just glancing at the build diffs, I looked at a simulator trace of one of the trivial ones, g++.old-deja/g++.mike/eh3.C (now calling abort), and apparently the unwind code gets lost and can't find it's way to the correct exception context. Which is what's "expected" when some code on the execution path from (the equivalent of) "throw" to ground zero of the exception handling (uw_init_context_1) is compiled without -fexceptions. Looking at the affected Makefile.in, I'm lost as to how that iterator thingy works, and with the section-local setting of c_flags. Is GNU make 3.81 not sufficient for this to work? But from gcc-testresults archives, I see no other regressions and no new bug reports so why was cris-elf the only platform affected (or if more, why so few platforms)? More fallout caused by the recent libgcc changes? brgds, H-P PS. cris-elf is bare-iron static libraries only, standard dwarf2-eh.
