From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11385 invoked by alias); 23 Jun 2009 12:24:41 -0000 Received: (qmail 11189 invoked by alias); 23 Jun 2009 12:24:18 -0000 Date: Tue, 23 Jun 2009 12:24:00 -0000 Message-ID: <20090623122418.11182.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "drow at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg01689.txt.bz2 ------- 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 -0000, 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