From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20839 invoked by alias); 30 May 2003 20:21:03 -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 20809 invoked from network); 30 May 2003 20:21:01 -0000 Received: from unknown (HELO zenia.red-bean.com) (12.223.225.216) by sources.redhat.com with SMTP; 30 May 2003 20:21:01 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h4UKU6Fq007875; Fri, 30 May 2003 15:30:06 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h4UKU0WT007871; Fri, 30 May 2003 15:30:00 -0500 To: Andrew Cagney Cc: Mark Kettenis , mludvig@suse.cz, gdb@sources.redhat.com, Alexandre Oliva Subject: Re: dwarf-frame.c question 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> From: Jim Blandy Date: Fri, 30 May 2003 20:21:00 -0000 In-Reply-To: <3ED693F5.9040108@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00419.txt.bz2 Andrew Cagney writes: > Discussed this with AlexO (of gcc). Let us ruin your day. > > This problem can occure even without recursion. Consider the C snippet: > > foo () > { > if (i) > abort (with, lots, of parameters) > do; normal; stuff; > } > > it can be turned into: > > branch !i, 1: > push with > push lots > push of > push parameters > call abort > 1: > do > normal > stuff > > The return address can end up pointing at the ``do'' / 1: line and > that's CFI info is definitly not correct for unwinding from abort(). It's worth pointing out that this problem is not possible to solve in general. If the compiler knows that a given call will never return, it would be completely correct for it to trash the stack, overwrite its saved return address, etc. before making the call. Since the older frames will never be used, they're dead, and code that makes them unfindable is just as correct as code which trashes the value of a dead variable. The only reason it's possible to generate CFI at all in the normal case is that the function itself needs to return, so the information must be there somewhere. Where that precondition doesn't hold, unwinding is only possible when the compiler is lazy. :)