[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC||jackie.rosen at hushmail dot com --- Comment #25 from Jackie Rosen jackie.rosen at hushmail dot com --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #24 from tschwinge at gcc dot gnu dot org 2010-03-31 15:49 --- Regression report for arm-none-linux-gnueabi: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01188.html Patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01505.html -- tschwinge at gcc dot gnu dot org changed: What|Removed |Added CC||tschwinge at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #23 from mikpe at it dot uu dot se 2009-10-21 10:48 --- (In reply to comment #8) (In reply to comment #7) With binutils from the 2.20 branch, and gcc from the 4.4 branch, including Jakub's patch, and excluding the current workaround from Ramana, I get: IIUC and to make things explicit, the work-around is needed for any binutils prior to the 2.20 branch until the backport is done. If the backport is committed we should pull out my work around as well. The backport has been committed now, so your PR41533 workaround should not be needed any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #21 from jakub at gcc dot gnu dot org 2009-10-19 12:15 --- Subject: Bug 40521 Author: jakub Date: Mon Oct 19 12:15:27 2009 New Revision: 152974 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152974 Log: Backport from mainline: 2009-10-16 Jakub Jelinek ja...@redhat.com PR debug/40521 * debug.h (struct gcc_debug_hooks): Add assembly_start hook. * cgraphunit.c (cgraph_optimize): Call it. * dwarf2out.c (dwarf2out_init): Move .cfi_sections printing into... (dwarf2out_assembly_start): ... here. New hook. (dwarf2out_debug_hooks): Add dwarf2out_assembly_start. * debug.c (do_nothing_debug_hooks): Do nothing for assembly_start hook. * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise. * sdbout.c (sdb_debug_hooks): Likewise. * vmsdbgout.c (vmsdbg_debug_hooks): Add vmsdbgout_assembly_start. (vmsdbgout_assembly_start): New hook. 2009-10-09 Jakub Jelinek ja...@redhat.com PR debug/40521 * dwarf2out.c (dwarf2out_init): Test whether HAVE_GAS_CFI_SECTIONS_DIRECTIVE is non-zero instead of checking it is defined. 2009-10-02 Jakub Jelinek ja...@redhat.com PR debug/40521 * configure.ac (HAVE_GAS_CFI_SECTIONS_DIRECTIVE): New test. * configure: Regenerated. * config.in: Regenerated. * dwarf2out.c (dwarf2out_do_cfi_asm): Return false if !HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame. (dwarf2out_init): If HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame, emit .cfi_sections .debug_frame directive. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/cgraphunit.c branches/gcc-4_4-branch/gcc/config.in branches/gcc-4_4-branch/gcc/configure branches/gcc-4_4-branch/gcc/configure.ac branches/gcc-4_4-branch/gcc/dbxout.c branches/gcc-4_4-branch/gcc/debug.c branches/gcc-4_4-branch/gcc/debug.h branches/gcc-4_4-branch/gcc/dwarf2out.c branches/gcc-4_4-branch/gcc/sdbout.c branches/gcc-4_4-branch/gcc/vmsdbgout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #22 from jakub at gcc dot gnu dot org 2009-10-19 12:21 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #20 from jakub at gcc dot gnu dot org 2009-10-17 07:28 --- Subject: Bug 40521 Author: jakub Date: Sat Oct 17 07:28:13 2009 New Revision: 152930 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152930 Log: PR debug/40521 * debug.h (struct gcc_debug_hooks): Add assembly_start hook. * cgraphunit.c (cgraph_optimize): Call it. * dwarf2out.c (dwarf2out_init): Move .cfi_sections printing into... (dwarf2out_assembly_start): ... here. New hook. (dwarf2out_debug_hooks): Add dwarf2out_assembly_start. * debug.c (do_nothing_debug_hooks): Do nothing for assembly_start hook. * dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise. * sdbout.c (sdb_debug_hooks): Likewise. * vmsdbgout.c (vmsdbg_debug_hooks): Add vmsdbgout_assembly_start. (vmsdbgout_assembly_start): New hook. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/dbxout.c trunk/gcc/debug.c trunk/gcc/debug.h trunk/gcc/dwarf2out.c trunk/gcc/sdbout.c trunk/gcc/vmsdbgout.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #18 from jakub at gcc dot gnu dot org 2009-10-16 14:55 --- When testing this, I've noticed a major problem with Ada, supposedly on the trunk as well when using latest binutils. The problem is that gnat_init_gcc_eh which can change flag_exceptions is called way too late, not from lang_hooks.init, but far after it. This means by the time dwarf2out_init is called flag_exceptions might be still 0 and thus .cfi_sections .dwarf_frame is emitted. But then gnat_init_gcc_eh changes flag_exception to 1 and excepts .eh_frame to be generated. The reason I've put .cfi_sections directive addition to dwarf2out.c is to allow the user to override it within inline assembly, so I don't want to emit it at the end of the file. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2009-10-16 17:35 --- When testing this, I've noticed a major problem with Ada, supposedly on the trunk as well when using latest binutils. Thanks for the heads up. The problem is that gnat_init_gcc_eh which can change flag_exceptions is called way too late, not from lang_hooks.init, but far after it. This means by the time dwarf2out_init is called flag_exceptions might be still 0 and thus .cfi_sections .dwarf_frame is emitted. But then gnat_init_gcc_eh changes flag_exception to 1 and excepts .eh_frame to be generated. Can we arrange for making it safe to set flag_exceptions from lang_hooks.init and then clear it in gnat_init_gcc_eh? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #17 from mikpe at it dot uu dot se 2009-10-13 12:52 --- Patch with proposed backport to 4.4 posted here: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00818.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #15 from sebastian dot huber at embedded-brains dot de 2009-10-12 11:36 --- (In reply to comment #13) Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some experiments to see which solution works best in 4.4. Is the target milestone 4.4.2 still true? In 4.4.2 20091008 the problem is still present. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #16 from mikpe at it dot uu dot se 2009-10-12 12:33 --- (In reply to comment #15) Is the target milestone 4.4.2 still true? In 4.4.2 20091008 the problem is still present. I have a patch for 4.4 which bootstraps and passes regression testing on i686-linux and powerpc64-linux. It also bootstraps on armv5tel-linux-gnueabi (the platform for which I want this fix) with Ramana's workaround reverted, but the test suite is not yet finished; it should be done around midnight today. I plan to submit the patch tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.2 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #14 from f dot frumento at ngi dot it 2009-10-11 22:52 ---
(In reply to comment #0)
Put this in main.c and build it with a 4.4-branch compiler using recent
binutils:
int main ()
{
return 0;
}
Versions:
GNU assembler (GNU Binutils) 2.19.51.20090611
i686-pc-linux-gnu-gcc (GCC) 4.4.1 20090611 (prerelease)
% i686-pc-linux-gnu-gcc -c main.c; objdump --wide -h main.o | grep ALLOC
0 .text 000a 0034 2**2 CONTENTS,
ALLOC, LOAD, READONLY, CODE
1 .data 0040 2**2 CONTENTS,
ALLOC, LOAD, DATA
2 .bss 0040 2**2 ALLOC
% i686-pc-linux-gnu-gcc -c -g main.c; objdump --wide -h main.o | grep ALLOC
0 .text 000a 0034 2**2 CONTENTS,
ALLOC, LOAD, READONLY, CODE
1 .data 0040 2**2 CONTENTS,
ALLOC, LOAD, DATA
2 .bss 0040 2**2 ALLOC
12 .eh_frame 0034 01c0 2**2 CONTENTS,
ALLOC, LOAD, RELOC, READONLY, DATA
We're using GAS's .cfi_startproc et cetera directives to generate debug
information. But they only generate .eh_frame, not .debug_frame.
I also noticed this problem on an ARM EABI target. ARM EABI does not use
.eh_frame, only .debug_frame and .ARM.exidx.
The easiest fix is to disable use of the CFI directives when we are trying to
generate .debug_frame. I believe GCC used to generate both .debug_frame and
.eh_frame for the same function. If we want both to gain the advantages of
using CFI directives (e.g. potentially accurate across inline asm), then we
need to teach gas to emit .debug_frame/.eh_frame/both as requested.
Hi all,
I've noticed ther behaviour differs for some platform
I've tested a cross compiler Gcc 4.4.1 on Cygwin and on Mac OSX 1.6,I've built
it from vanilla sources (gcc.gnu.org), the final target is M68K/Coldfire
on mac no problem at all while on cygwin i've got a no memory region
...omissis... for .eh_frame error message, i've built the same files just
checked out from svn repository. While i've solved disabling debug options i
can't use this setup for long, I've also modified the linker script as follow:
MEMORY
{
flash : ORIGIN = 0x000, LENGTH = 0x10
dpram : ORIGIN = 0x0FFFE000, LENGTH = 0x1000
}
SECTIONS {
.text : {*(boot) *(text) *(eh_frame)} flash
.data : {} dpram
.bss : {} dpram
eh_frame :{} flash
/DISCARD/ : { *(eh_*)}
}
but it seems that on cygwin the /DISCARD/ special command doesn't work so my
binary files is larger than the mac generated one.
Any idea ?
--
f dot frumento at ngi dot it changed:
What|Removed |Added
CC||f dot frumento at ngi dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #9 from mikpe at it dot uu dot se 2009-10-09 18:28 --- I've been testing a backport of Jakub's patch to gcc-4.4, but it breaks bootstrap on i686-linux with binutils-2.18.50.0.6 (Fedora 9) because stage1 gcc outputs .cfi_sections directives even though the assembler doesn't support them. Current gcc-4.5 bootstraps Ok on the same machine. The configure test correctly detects that cfi sections don't work with this as, and records that with #define HAVE_GAS_CFI_SECTIONS_DIRECTIVE 0. In gcc-4.5 dwarf2out_do_cfi_asm() returns true. The code in dwarf2out_init() inside #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE finds that USING_SJLJ_EXCEPTIONS is false and !flag_exceptions is also false, so the call to emit a .cfi_sections directive is not made. (!flag_unwind_tables varies, but it does not matter since it's with !flag_exceptions which always is false.) In gcc-4.4 dwarf2out_do_cfi_asm() also returns true. The code in dwarf2out_init() finds that USING_SJLJ_EXCEPTIONS is false but both !flag_unwind_tables and !flag_exceptions are true, so a .cfi_sections directive is emitted, causing the assembler to signal an error. One thing that I find strange is that dwarf2out_do_cfi_asm() unconditionally tests HAVE_GAS_CFI_SECTIONS_DIRECTIVE in an if (!...), which works since that symbol is #defined as 0 or 1, while dwarf2out_init() instead has an #ifdef HAVE_GAS_CFI_SECTIONS_DIRECTIVE around the conditional output of the directive. Shouldn't that #ifdef be an #if? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #10 from jakub at gcc dot gnu dot org 2009-10-09 18:54 ---
Yes, it is a bug and I'll change it, but I wonder why it makes a difference
(unless you're using PCH). .cfi_sections is only emitted if:
if (dwarf2out_do_cfi_asm ())
{
#ifndef TARGET_UNWIND_INFO
if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables !flag_exceptions))
#endif
fprintf (asm_out_file, \t.cfi_sections\t.debug_frame\n);
}
#endif
but if !HAVE_CFI_SECTIONS_DIRECTIVE, dwarf2out_do_cfi_asm () has:
if (!HAVE_GAS_CFI_SECTIONS_DIRECTIVE)
{
#ifdef TARGET_UNWIND_INFO
return false;
#else
if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables !flag_exceptions))
return false;
#endif
}
i.e. will return false under the exact same condition that dwarf2_init would
allow it. The only exception is when using PCH, you could create PCH with
saved_do_cfi_asm true and then load it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #11 from jakub at gcc dot gnu dot org 2009-10-09 19:07 --- Subject: Bug 40521 Author: jakub Date: Fri Oct 9 19:07:23 2009 New Revision: 152598 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152598 Log: PR debug/40521 * dwarf2out.c (dwarf2out_init): Test whether HAVE_GAS_CFI_SECTIONS_DIRECTIVE is non-zero instead of checking it is defined. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #12 from jakub at gcc dot gnu dot org 2009-10-09 19:17 ---
Ah, now I see it in the 4.4 version. Your backport is wrong then, you must not
return true from dwarf2out_do_cfi_asm when !eh_personality_libfunc, but
HAVE_GAS_CFI_SECTIONS_DIRECTIVE is 0 and not emitting normal unwind info.
Either you want:
int
dwarf2out_do_cfi_asm (void)
{
int enc;
#ifdef MIPS_DEBUGGING_INFO
return false;
#endif
if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ())
return false;
if (saved_do_cfi_asm)
return true;
if (eh_personality_libfunc)
{
if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE)
return false;
/* Make sure the personality encoding is one the assembler can support.
In particular, aligned addresses can't be handled. */
enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2,/*global=*/1);
if ((enc 0x70) != 0 (enc 0x70) != DW_EH_PE_pcrel)
return false;
enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0,/*global=*/0);
if ((enc 0x70) != 0 (enc 0x70) != DW_EH_PE_pcrel)
return false;
}
if (!HAVE_GAS_CFI_SECTIONS_DIRECTIVE)
{
#ifdef TARGET_UNWIND_INFO
return false;
#else
if (USING_SJLJ_EXCEPTIONS || (!flag_unwind_tables !flag_exceptions))
return false;
#endif
}
saved_do_cfi_asm = true;
return true;
}
or move the !HAVE_GAS_CFI_SECTIONS_DIRECTIVE tests in between if
(saved_do_cfi_asm) return true; and if (!eh_personality_libfunc) return true;.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #13 from mikpe at it dot uu dot se 2009-10-09 19:51 --- Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some experiments to see which solution works best in 4.4. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #7 from doko at ubuntu dot com 2009-10-08 15:17 --- With binutils from the 2.20 branch, and gcc from the 4.4 branch, including Jakub's patch, and excluding the current workaround from Ramana, I get: $ gcc -c main.c $ objdump --wide -h main.o | grep ALLOC 0 .text 001c 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0050 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0050 2**0 ALLOC $ gcc -c -g main.c $ objdump --wide -h main.o | grep ALLOC 0 .text 001c 0034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0050 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0050 2**0 ALLOC OpenOffice rebuilt with these tools doesn't crash anymore. See PR ld/10695 and http://qa.openoffice.org/issues/show_bug.cgi?id=105359 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #8 from ramana at gcc dot gnu dot org 2009-10-08 15:36 --- (In reply to comment #7) With binutils from the 2.20 branch, and gcc from the 4.4 branch, including Jakub's patch, and excluding the current workaround from Ramana, I get: IIUC and to make things explicit, the work-around is needed for any binutils prior to the 2.20 branch until the backport is done. If the backport is committed we should pull out my work around as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-02 18:52 --- Subject: Bug 40521 Author: jakub Date: Fri Oct 2 18:52:15 2009 New Revision: 152414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152414 Log: PR debug/40521 * configure.ac (HAVE_GAS_CFI_SECTIONS_DIRECTIVE): New test. * configure: Regenerated. * config.in: Regenerated. * dwarf2out.c (dwarf2out_do_cfi_asm): Return false if !HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame. (dwarf2out_init): If HAVE_GAS_CFI_SECTIONS_DIRECTIVE and not emitting .eh_frame, emit .cfi_sections .debug_frame directive. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-01 15:44 --- http://sources.redhat.com/ml/binutils/2009-10/msg00028.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.4.1 |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-23 11:09 --- I think if we don't want to emit .eh_frame, we should just default to -fno-dwarf2-cfi-asm. But if we do want to generate it, I fail to see what do we gain by also generating .debug_frame. Duplicating the same info, in one case in a more compat form, doesn't look like a good idea. If we decide to teach gas to emit both .eh_frame and .debug_frame, or just .eh_frame, or just .debug_frame from CFI directives (controlled using some directive or option?), then one thing that needs solving is that gas will have to hardcode a register mapping table for ppc*, because on ppc .eh_frame uses a different register numbering from .debug_frame. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #4 from drow at gcc dot gnu dot org 2009-06-23 12:24 --- Subject: Re: [4.4/4.5 Regression] -g causes GCC to generate .eh_frame On Tue, Jun 23, 2009 at 11:09:48AM -, jakub at gcc dot gnu dot org wrote: I think if we don't want to emit .eh_frame, we should just default to -fno-dwarf2-cfi-asm. But if we do want to generate it, I fail to see what do we gain by also generating .debug_frame. Duplicating the same info, in one case in a more compat form, doesn't look like a good idea. That sounds reasonable. At one point there was a proposal to emit completely accurate unwind information for .debug_frame, and skip some prologue/epilogue information in .eh_frame; if we do that, obviously we need both sets of output, but otherwise we don't. We should make this be consistent though, not depend on -fno-dwarf2-cfi-asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #1 from drow at gcc dot gnu dot org 2009-06-22 15:20 --- CC'ing some people who know about CFI for opinions on the best resolution. Do we need a new gas option and/or CFI directive for this? -- drow at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||aoliva at gcc dot gnu dot ||org, jakub at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame
--- Comment #2 from drow at gcc dot gnu dot org 2009-06-22 15:22 --- I've confirmed that older GCC emits both .debug_frame and .eh_frame. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521
