From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19789 invoked by alias); 16 Mar 2004 20:51: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 19762 invoked from network); 16 Mar 2004 20:51:09 -0000 Received: from unknown (HELO miranda.se.axis.com) (212.209.10.220) by sources.redhat.com with SMTP; 16 Mar 2004 20:51:09 -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 i2GKoW8u015256; Tue, 16 Mar 2004 21:50:32 +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 i2GKoVZR017610; Tue, 16 Mar 2004 21:50:31 +0100 Received: (from hp@localhost) by ignucius.se.axis.com (8.12.8p1/8.12.8/Debian-2woody1) id i2GKoSSW017606; Tue, 16 Mar 2004 21:50:28 +0100 Date: Fri, 19 Mar 2004 00:09:00 -0000 Message-ID: <200403162050.i2GKoSSW017606@ignucius.se.axis.com> From: Hans-Peter Nilsson To: drow@false.org CC: orjan.friberg@axis.com, gdb-patches@sources.redhat.com, hans-peter.nilsson@axis.com In-reply-to: <20040316191301.GA13244@nevyn.them.org> (message from Daniel Jacobowitz on Tue, 16 Mar 2004 14:13:01 -0500) Subject: Re: [CRIS] dwarf2 frame sniffer problem? X-SW-Source: 2004-03/txt/msg00365.txt.bz2 Message-ID: <20040319000900.i5QZ-S6qdBnpwrVp32SMrJokZ4dMFBHawNquA-gMCXY@z> > 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? > 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... brgds, H-P