From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4986 invoked by alias); 23 Jun 2009 11:10:07 -0000 Received: (qmail 4846 invoked by uid 48); 23 Jun 2009 11:09:47 -0000 Date: Tue, 23 Jun 2009 11:10:00 -0000 Message-ID: <20090623110947.4845.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: "jakub 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/msg01685.txt.bz2 ------- 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