From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17624 invoked by alias); 30 May 2003 20:44:57 -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 17599 invoked from network); 30 May 2003 20:44:56 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 30 May 2003 20:44:56 -0000 Received: from livre.redhat.lsd.ic.unicamp.br (to-dhcp6.toronto.redhat.com [172.16.14.106]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h4UKitK21258; Fri, 30 May 2003 16:44:55 -0400 Received: from livre.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by livre.redhat.lsd.ic.unicamp.br (8.12.8/8.12.8) with ESMTP id h4UKitdj010823; Fri, 30 May 2003 17:44:55 -0300 Received: (from aoliva@localhost) by livre.redhat.lsd.ic.unicamp.br (8.12.8/8.12.8/Submit) id h4UKisFb010819; Fri, 30 May 2003 17:44:54 -0300 To: Jim Blandy Cc: Andrew Cagney , Mark Kettenis , mludvig@suse.cz, gdb@sources.redhat.com 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: Alexandre Oliva Organization: GCC Team, Red Hat Date: Fri, 30 May 2003 20:44:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00422.txt.bz2 On May 30, 2003, Jim Blandy wrote: > Andrew Cagney writes: >> One idea (the origins of which are unknown) is for the compiler to >> generate CFI info containing no addresses and have GDB look for that >> dependant on the PC address being obtained using return or resume >> (sigtramp, sentinel). > I don't understand this. Could you explain the idea in more detail? The idea Andrew and I came up with was initially to get GCC to emit a useless nop (especially when compiling without optimization) that would hold the post-call CFI information. Afterwards, one of us thought that, even if the nop was removed, we could still emit CFI information for the now-empty region, and have GDB (or, even better, the DWARF3 spec) recognize this as a special case for non-returning calls. I agree with you that, in general, the CFI information might just indicate that the stack was trashed beyond recognition, but often the info will still be there, and there's no reason to not present the information in a usable format in such cases. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer