[Bug target/47829] New: no .eh_frame_hdr table will be created.
kargl at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Feb 21 07:03:00 GMT 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47829
Summary: no .eh_frame_hdr table will be created.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: kargl@gcc.gnu.org
FreeBSD updated its ancient version of in-system binutils
to 2.17. In doing so, an assert is firing in ld. The
problem was addressed in the in FreeBSD's ancient gcc with
this commit
--------------------------------------------------------------
laptop:root[211] svn log -r 209294 | more
------------------------------------------------------------------------
r209294 | kib | 2010-06-18 04:09:51 -0700 (Fri, 18 Jun 2010) | 16 lines
Often reported issue with newer ld is:
error in /usr/lib/crtendS.o(.eh_frame); no .eh_frame_hdr table will be created.
The issue is that crtend is compiled with unwind table, and also it
places the special CIE into the .eh_frame indicating the end of section,
that is located before generated unwind table. New ld has assertion that
verifies that closing CIE is indeed the last CIE, causing the crypting
message to be issued, and refusing to generate dwarf unwind.
Add -fno-asynchronous-unwind-tables to disable unwind table generation
for crtbegin/crtend. While there, disable omitting the frame pointer [1].
This patch fixes the issue for GCC trunk on i686-*-freebsd.
laptop:kargl[246] svn diff gcc/config.gcc
Index: gcc/config.gcc
===================================================================
--- gcc/config.gcc (revision 170344)
+++ gcc/config.gcc (working copy)
@@ -1210,6 +1210,7 @@ x86_64-*-elf*)
;;
i[34567]86-*-freebsd*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
${fbsd_tm_file} i386/freebsd.h"
+ tmake_file="${tmake_file} i386/t-crtstuff"
;;
x86_64-*-freebsd*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
${fbsd_tm_file} i386/x86-64.h i386/freebsd.h i386/freebsd64.h"
More information about the Gcc-bugs
mailing list