From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6384 invoked by alias); 16 Mar 2004 23:38:41 -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 6339 invoked from network); 16 Mar 2004 23:38:38 -0000 Received: from unknown (HELO miranda.se.axis.com) (212.209.10.220) by sources.redhat.com with SMTP; 16 Mar 2004 23:38:38 -0000 Received: from ignucius.se.axis.com (ignucius.se.axis.com [10.13.1.18]) by miranda.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id i2GNc18u014906; Wed, 17 Mar 2004 00:38:01 +0100 Received: from ignucius.se.axis.com (localhost [127.0.0.1]) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) with ESMTP id i2GNc1ZR013683; Wed, 17 Mar 2004 00:38:01 +0100 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id i2GNc03e013679; Wed, 17 Mar 2004 00:38:00 +0100 Date: Fri, 19 Mar 2004 00:09:00 -0000 Message-ID: <200403162338.i2GNc03e013679@ignucius.se.axis.com> From: Hans-Peter Nilsson To: drow@false.org CC: hans-peter.nilsson@axis.com, orjan.friberg@axis.com, gdb-patches@sources.redhat.com In-reply-to: <20040316222709.GA19066@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 16 Mar 2004 17:27:09 -0500) Subject: Re: [CRIS] dwarf2 frame sniffer problem? X-SW-Source: 2004-03/txt/msg00375.txt.bz2 Message-ID: <20040319000900.DjYVL03M_kHV5L9nS_k9a70f_clyX3EBL40DF8_Vj-w@z> > 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. > > 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? ;-) brgds, H-P