From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24908 invoked by alias); 16 Mar 2004 23:58:17 -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 24890 invoked from network); 16 Mar 2004 23:58:15 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 16 Mar 2004 23:58:15 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B3ORr-0005fF-Jg; Tue, 16 Mar 2004 18:58:15 -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: <20040316235815.GA21714@nevyn.them.org> Mail-Followup-To: Hans-Peter Nilsson , orjan.friberg@axis.com, gdb-patches@sources.redhat.com References: <20040316222709.GA19066@nevyn.them.org> <200403162338.i2GNc03e013679@ignucius.se.axis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403162338.i2GNc03e013679@ignucius.se.axis.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00376.txt.bz2 Message-ID: <20040319000900.eblwSDE8sqkP4v9X9gxEPiPBrd4c-m2d0pe-DYWQp44@z> On Wed, Mar 17, 2004 at 12:38:00AM +0100, Hans-Peter Nilsson wrote: > > Date: Tue, 16 Mar 2004 17:27:09 -0500 > > From: Daniel Jacobowitz > > > 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 > > > > 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. > > *When* do things go wrong? Is it all gdb run-type commands all > the time, or is it just when (manually) looking around after > (manually) doing "stepi" into the prologue but not out of it? > Something else? Just curious in case you have the answer at > hand; I'll try and pursue splitting up EH & debug info. When you use "next", at a function call, GDB will step - then after that instruction, it will try to find the frame ID. And then it will unwind to find the caller's frame ID, and step or breakpoint/continue until we get back there. So you've lost if you don't have the ability to unwind at the first instruction. Same if you "step" over something you don't have debug info for. I'm sure there are more things that will go wrong; I don't know how much. > > > > 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. > > Yeah, flag_asynchronous_unwind_tables means all that. ISTR Java > and Ada uses that, or should. > > > GDB gets _very_ cranky when unwind information is specified but not > > correct. > > Opportunities for improvements in the failure mode here? ;-) Not really. You have unwind info; we have to either trust it, or not. It's not failing to unwind, it's unwinding and providing incorrect information... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer