From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24493 invoked by alias); 5 Aug 2004 20:18:38 -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 24486 invoked from network); 5 Aug 2004 20:18:37 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 5 Aug 2004 20:18:37 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 4DCCC357B; Thu, 5 Aug 2004 13:18:36 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.11/8.12.9) with ESMTP id i75KIYuX023217; Thu, 5 Aug 2004 13:18:34 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.11/8.12.11/Submit) id i75KIXAZ023214; Thu, 5 Aug 2004 13:18:33 -0700 Date: Thu, 05 Aug 2004 20:18:00 -0000 Message-Id: <200408052018.i75KIXAZ023214@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Mark Kettenis Cc: cagney@gnu.org, gdb@sources.redhat.com Subject: Re: Identifying bottom-of-stack In-Reply-To: Mark Kettenis's message of Thursday, 5 August 2004 11:41:23 +0200 <200408050941.i759fNJE010167@juw15.nfra.nl> X-Windows: no hardware is safe. X-SW-Source: 2004-08/txt/msg00082.txt.bz2 > The problem is that a zero frame pointer is an insufficient condition > to determine the bottom of the stack. With code generated with > -fno-frame-pointer, the register that was traditionally used for the > frame pointer can be used for other purposes, and may very well > contain zero. Of course, but if there is no CFI then there is nothing better to do than assume the frame pointer is a frame pointer and try to use it, no? > There is. On amd64 -fno-frame-pointer is the default. I know that. > So this effort of not generating CFI and clearing the framepointer is > pointless. Clearing the frame pointer is not pointless since the ABI document suggests doing exactly that. Avoiding generating CFI is not pointless since it is better than generating CFI that is incorrect. Anyway, I didn't ask if these things were pointless, I asked if they were sufficient. If gdb doesn't consider a zero frame pointer register in a frame with no CFI sufficient indication of being the outermost frame, then that answers the question. You don't need to justify the choice of gdb's semantics on this to me, just clarify them to me. [Andrew says:] > > > - GLIBC marking those outermost frames with CFI indicating that both the > > > CFA and the RA are "unknown"? > > s/unknown/undefined/ Perhaps this addresses Mark's request for precision in terminology, but it doesn't clarify anything for me. Does this "undefined" mean the "undefined" used in the DWARF spec? Does DW_CFA_def_cfa with some register + DW_CFA_undefined on that register in fact yield this? Is that the only way to produce it? Is it the optimal way? These are the questions I meant to imply when I asked, "What would such CFI look like exactly?" If you want me to do it, step one is always to specify it completely. Thanks, Roland