From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13817 invoked by alias); 16 Mar 2004 22:27:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13796 invoked from network); 16 Mar 2004 22:27:10 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Mar 2004 22:27:10 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B3N1h-0004zQ-JG; Tue, 16 Mar 2004 17:27:09 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Hans-Peter Nilsson Cc: orjan.friberg@axis.com, gdb-patches@sources.redhat.com Subject: Re: [CRIS] dwarf2 frame sniffer problem? Message-ID: <20040316222709.GA19066@nevyn.them.org> Mail-Followup-To: Hans-Peter Nilsson , orjan.friberg@axis.com, gdb-patches@sources.redhat.com References: <20040316191301.GA13244@nevyn.them.org> <200403162050.i2GKoSSW017606@ignucius.se.axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403162050.i2GKoSSW017606@ignucius.se.axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00369.txt.bz2 Message-ID: <20040319000900.mPy8o0mvPbw5JX_vuvBEH4cTm-R-wJMywNNCPLUhfYI@z> On Tue, Mar 16, 2004 at 09:50:28PM +0100, Hans-Peter Nilsson wrote: > > Date: Tue, 16 Mar 2004 14:13:01 -0500 > > From: Daniel Jacobowitz > > Hi Dan. > > > On Tue, Mar 16, 2004 at 05:26:16PM +0100, Orjan Friberg wrote: > > > Would emitting that label *after* the prologue be an option (i.e. > > > leaving us without dwarf2 information while still in the prologue)? > > > > Nope. Then when you step into the prologue (i.e. "step over") unwind > > information will be incorrect. > > Is that the whole effect, incorrectness for gdb usage *inside* > the prologue? Probably yes. So backtraces will not be affected but every bit of running is likely to misbehave. > > I recommend taking a look at the patch where I implemented this for > > Thumb, or at the m68k implementation. > > I know *how* to do it, I just want to prod a little if there's a > way to avoid dwarf2 info (specifically advance_loc directives) > not necessary for EH unwinding and still have it working for gdb > modulo stepping inside the prologue. It worked fine until gdb > started to use dwarf2 too. :-) > > As you know, the same info ends up in the EH unwind info as > well, and we don't want that to be larger than absolutely > necessary. (And as I suppose you *also* know, mentioned for the > record, "disk is cheap" is definitely not true when the disk is > solid-state memory.) Yeah, there should be a way to emit > different dwarf2 EH from that for debug. Hmm, maybe it would > work to just withholding all advance_loc codes except the last > one for for_eh && !flag_asynchronous_unwind_tables in > gcc/dwarf2out.c (sort of). And a target-specific hook for > "advancing loc", which could use the new gas dwarf2 directives > so it's not always advance_loc4. Getting off-topic here... Yeah, that may be the best way to solve this - emit more info in the .debug_frame than in .eh_frame, if you aren't supporting asynchronous unwinding. Like throwing from signal handlers taken during prologues, et cetera. GDB gets _very_ cranky when unwind information is specified but not correct. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer