Here's the dwarf2 patch I'm using. With the change to checking __LIBGCC_EH_FRAME_SECTION_NAME__, an undefined reference to __EH_FRAME_BEGIN__ gets emitted within __main.o. The actual symbol for it is defined within cygming-crtbegin.c (crtbegin.o) which is listed before __main.o when linking libgcc leaving the undefined reference unresolved. This restores behavior to the 4.9 branch only for this specific instance (confirmed by comparing pre-processed output). Will update with bugtraq info.
Relevant references: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00409.html http://gcc.gcc.gnu.narkive.com/RMY4RcbE/asm-output-section-name-cleanup-patch-problem diff --git a/libgcc/libgcc2.c b/libgcc/libgcc2.c index c737620..e5ab209 100644 --- a/libgcc/libgcc2.c +++ b/libgcc/libgcc2.c @@ -2211,7 +2211,7 @@ TRANSFER_FROM_TRAMPOLINE /* Some ELF crosses use crtstuff.c to provide __CTOR_LIST__, but use this code to run constructors. In that case, we need to handle EH here, too. */ -#ifdef __LIBGCC_EH_FRAME_SECTION_NAME__ +#ifdef EH_FRAME_SECTION_NAME #include "unwind-dw2-fde.h" extern unsigned char __EH_FRAME_BEGIN__[]; #endif @@ -2231,7 +2231,7 @@ __do_global_dtors (void) (*(p-1)) (); } #endif -#if defined (__LIBGCC_EH_FRAME_SECTION_NAME__) && !defined (HAS_INIT_SECTION) +#if defined (EH_FRAME_SECTION_NAME) && !defined (HAS_INIT_SECTION) { static int completed = 0; if (! completed) @@ -2250,7 +2250,7 @@ __do_global_dtors (void) void __do_global_ctors (void) { -#ifdef __LIBGCC_EH_FRAME_SECTION_NAME__ +#ifdef EH_FRAME_SECTION_NAME { static struct object object; __register_frame_info (__EH_FRAME_BEGIN__, &object); On Wed, May 13, 2015 at 2:59 PM, Alexpux <alex...@gmail.com> wrote: > >> 13 мая 2015 г., в 15:44, Matt Breedlove <breedlove.m...@gmail.com> >> написал(а): >> >> Building with GCC release 5.1.0 or the gcc-5-branch configured in the >> way the PKGBUILD file is described fails while building for >> i686/dwarf-2. >> >> There's a patch found on the gcc-patches list that allows it to go >> through described here: >> >> http://sourceforge.net/p/mingw-w64/mailman/message/34101954/ >> > I’m still can’t build DWARF toolchains with this patch. > >> I'm able to build for both x86-64 and i686 as a result. There's also >> some fixes for doing LTO builds described there though less likely to >> matter for msys2 since it doesnt use it. That said, there's a fairly >> serious bug within 5.1.0 preventing building anything with LTO that is >> probably worth holding off for unless Kai's patch from the following >> url is applied: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 >> >> Using the combined fixes, I can also bootstrap with both thin and fat >> LTO. Hope this helps. >> >> Thanks for the effort, >> Matt >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Msys2-users mailing list >> Msys2-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/msys2-users > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
