From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15003 invoked by alias); 3 Jun 2003 15:58:51 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14947 invoked from network); 3 Jun 2003 15:58:50 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 3 Jun 2003 15:58:50 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h53FwnH12964 for ; Tue, 3 Jun 2003 11:58:50 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h53FwjT14268; Tue, 3 Jun 2003 11:58:45 -0400 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h53Fwi015563; Tue, 3 Jun 2003 08:58:44 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id h53Fulm19400; Tue, 3 Jun 2003 08:56:47 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 03 Jun 2003 15:58:00 -0000 From: Richard Henderson To: Jim Blandy Cc: Andrew Cagney , Mark Kettenis , mludvig@suse.cz, gdb@sources.redhat.com, Alexandre Oliva Subject: Re: dwarf-frame.c question Message-ID: <20030603155646.GA19391@redhat.com> References: <3ED381CB.5050207@suse.cz> <200305291544.h4TFi7aL031832@elgar.kettenis.dyndns.org> <3ED66564.1020506@redhat.com> <200305292222.h4TMMmGm000694@elgar.kettenis.dyndns.org> <3ED693F5.9040108@redhat.com> <3ED7BFD1.7060902@redhat.com> <20030603054552.GD19075@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-06/txt/msg00031.txt.bz2 On Tue, Jun 03, 2003 at 01:30:56AM -0500, Jim Blandy wrote: > Since we're unwinding a frame which will never really be unwound, we > can have that do anything we want. So, if a function never returns, > why not have the compiler emit CFI that restores the state just > *before* the call insn was executed, not after it returns? The > unwound PC would point at the call insn itself. Hmm. You mean that the unwind info for "abort" itself would change to say that the return address was something other than it really is? Certainly this is possible. If the function has the noreturn attribute GCC could frob the return address with DW_CFA_expression. Does this have any other adverse side effects though? How about the fact that abort is often written in assembly language in libc, and so may not have any specific unwind information at all? r~